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Preface 

de la deuxieme edition 



You'd like to learn about modern best practices in Enterprise Java, with Spring as the unifying 
factor? This is the book to read! It is my pleasure to introduce one of the very first books that 
focus on the latest generations of the Spring Framework: version 2.5 and 3.0, introducing 
strong support for source-level metadata annotations that complement Spring's traditional 
XML-based approach. Whether Spring newbie or seasoned Spring developer, there is plenty 
for you to discover. 

This book discusses Spring in a Java 5 and Java EE 5 world of annotation-based programming 
models. It paints a complete picture of Spring's philosophy with respect to annotation-based 
dependency injection and annotation-based metadata overall, while pointing out that traditional 
approaches using external metadata play a key role as well. The authors will be guiding you 
through the choices, pointing out the limits and trade-offs involved. 

In this second edition, the authors did a fresh update to the latest mainstream trends in the 
Spring ecosystem: Spring 2.5's annotation-based MVC programming model is thoroughly 
covered, as is the annotation-based test context framework which was introduced in Spring 2.5 as 
well. This represents where the Spring community is going and puts much-deserved focus on 
the "hidden power" of the annotation-based model, such as flexible method signatures. 

This book is not just up to date; it is even ahead of its time! The authors cover Spring 3.0 at the 
end of its milestone phase already. Key developments in the MVC space, such as Spring 3.0's 
comprehensive REST support, are covered next to Spring 2.5's feature set. It shows that 
Spring 2.5 was "half way to 3.0", since 3.0 is really all about completing the mission that 
2.5 started! This book's side -by-side discussion indicates a smooth migration path as well. 

Finally, Spring is more than just the Spring Framework nowadays. Spring is rather a whole 
portfolio of projects: including Spring Security, Spring Web Flow, Spring Web Services, 
Spring Batch, as well as Spring Dynamic Modules and SpringSource dm Server. Beyond 
covering the core Spring Framework itself, this book also discusses those key portfolio projects 
and demonstrates their practical use in application architectures. 

Enjoy! 

Jiirgen HOLLER, 

Spring Framework project lead, VP & Distinguished Engineer, SpringSource 
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Vous souhaitez en savoir plus sur les meilleures pratiques pour le developpement d' applica- 
tions d'entreprise avec le framework Spring comme socle technique ? Voici le livre qu'il vous 
faut ! C'est avec plaisir que je vous presente un des tout premiers ouvrages sur les dernieres 
generations du framework Spring, a savoir les versions 2.5 et 3.0, qui proposent notamment 
une utilisation avancee des annotations pour completer la traditionnelle approche XML de 
Spring. Que vous soyez un developpeur Spring novice ou aguerri, vous y apprendrez beaucoup. 

Ce livre traite de Spring dans le monde de Java 5 et de Java EE 5, dont les modeles de 
programmation s'appuient fortement sur les annotations. II dresse un portrait complet de la 
philosophie de Spring quant a l'injection de dependances et a la gestion de metadonnees de 
maniere generate via des annotations, sans negliger les approches traditionnelles fondees sur 
des metadonnees externes, qui jouent aussi un role primordial. Les auteurs expliquent les bons 
choix a faire, en mettant en evidence les avantages et les inconvenients de chacun d'eux. 

Dans cette deuxieme edition, F effort des auteurs a porte sur la couverture exclusive des toutes 
dernieres tendances de l'ecosysteme Spring, comme le modele de programmation de Spring 
MVC ou le framework de tests unitaires, tous deux fondee sur les annotations et introduits 
dans Spring 2.5. II s'agit la du chemin directeur suivi par la communaute Spring, qui met en 
avant la puissance cachee d'un modele fonde sur les annotations du fait de la grande flexibilite 
qu'il offre pour la signature des methodes. 

Cet ouvrage n'est pas une simple mise a jour : il est meme en avance sur son temps ! Les 
auteurs couvrent Spring 3.0, dans la phase finale de ses milestones successifs. Les dernieres 
nouveautes de la partie MVC, telles que le support REST introduit dans Spring 3.0, sont aussi 
bien couvertes que les fonctionnalites specifiques de Spring 2.5. Cela demontre que Spring 
2.5 avait fait la moitie du chemin vers Spring 3.0 et que cette derniere version complete la 
mission commencee par la version 2.5. 

Spring n'est desormais plus seulement un framework, mais un portfolio complet de projets, 
avec notamment Spring Security, Spring Web Flow, Spring Web Services, Spring Batch, mais 
aussi Spring Dynamic Modules et l'outil dm Server. Ce livre ne couvre pas le seul framework 
Spring, mais va plus loin en traitant de ces projets cles du portfolio et en montrant leur usage 
dans les applications d'entreprise. 

Bonne lecture ! 

Jurgen HOLLER 

Cofondateur et responsable du developpement de Spring Framework, SpringSource 
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French readers have had to wait longer than most for a book on Spring in their native 
language. However, the wait has not been in vain, and they are fortunate in this, the first book 
on Spring in French. 

It is almost five years since I wrote the first code towards what would later become the Spring 
Framework. The open source project formally began in February 2003, soon making the 
product far more than any individual could achieve. Since that time, Spring has become 
widely used worldwide, powering applications as diverse as retail banking portals; airline 
reservation systems; the French online tax submission system; payment engines handling 
inter-bank transfers, salaries and utility bills; search engines; government agency portals 
including that of the European Patent Office; critical scientific research systems; logistics 
solutions; and football web sites. In that time, Spring also spawned a rich literature, in a variety 
of languages. 

This book does an excellent job, not merely of describing what Spring does, and how, but the 
central issue of why. Excellent examples illustrate the motivation for important Spring 
concepts and capabilities, making it not merely a book about a particular product, but a valuable 
book about writing effective server-side Java applications. 

While this book is ideal as an introduction to Spring and modern concepts such as Depen- 
dency Injection and Aspect Oriented Programming, it always respects the reader. The authors 
never write down to their readership. While their experience stands out, and they offer clear 
guidance as to best practice, the reader feels involved in their discussion of architectural choices 
and trade-offs. 

The content is not only up to date, but broad in scope and highly readable. Enterprise Java is 
a dynamic area, and open source projects are particularly rapidly moving targets. Spring has 
progressed especially rapidly in the last six months, with work leading up to the final release 
of Spring 2.0. The authors of this book have done a remarkable job of writing about Spring 2.0 
features as soon as they have stabilized. The coverage of AJAX is also welcome. 

The writing style is clear and to the point, making the book a pleasure to read. 
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Finally, the authors' commitment to providing a realistic sample application (rather than the 
simplistic effort that mars many books), is shown by the fact that Tudu Lists has become a 
viable open source project in its own right. 

I highly recommend this book to all those new to the Spring Framework or wishing to deepen 
their understanding of it, as well as those who wish to understand the current state of enter- 
prise Java development. 

Rod JOHNSON 

Founder, Spring Framework, CEO, SpringSource 



Si les lecteurs francophones ont du patienter plus que d'autres pour avoir acces a un livre sur 
Spring ecrit dans leur langue, leur attente n'aura pas ete vaine, puisque ce premier ouvrage en 
francais dedie a Spring est une grande reussite. 

Voici bientot cinq ans que j'ai ecrit les premieres lignes du code de ce qui allait devenir le 
framework Spring. Le projet Open Source lui-meme n'a reellement debute qu'en fevrier2003, 
pour aboutir rapidement a un produit outrepassant de beaucoup ce qu'une seule personne 
aurait pu realiser. Aujourd'hui, Spring est largement utilise a travers le monde, dans des appli- 
cations aussi diverses que des portails bancaires publics, des systemes de reservation de billets 
d' avion, le systeme francais de declaration de revenus en ligne, des moteurs de paiements 
assurant les transferts interbancaires ou la gestion de la paie et des factures, des moteurs de 
recherche, des portails de services gouvernementaux, dont celui de 1' Office europeen des 
brevets, des systemes critiques de recherche scientifique, des solutions de logistique ou des 
sites... dedies au football. Durant toute cette periode, Spring a fait l'objet d'une abondante 
litterature, dans un grand nombre de langues. 

Au-dela de la description de ce que fait Spring et de la facon dont il le fait, toute l'originalite 
de ce livre reside dans sa facon de repondre a la question centrale du pourquoi. Les tres bons 
exemples qui illustrent les motivations ayant conduit a F elaboration des concepts et des fonc- 
tionnalites fondamentales de Spring en font, bien plus qu'un simple manuel de prise en main, 
un ouvrage de reference pour quiconque souhaite realiser efficacement des applications Java 
cote serveur. 

Ideal pour une introduction a Spring et a des concepts aussi modernes que l'injection de 
dependances ou la programmation orientee aspect, ce livre respecte en outre toujours le 
lecteur, les auteurs s'etant fait un point d'honneur de ne jamais le prendre de haut. Tout en 
profitant de leur vaste experience et de leur clair expose des meilleures pratiques, le lecteur se 
sent continuellement implique dans leur presentation critique des choix d' architecture et des 
compromis qui en decoulent. 

Le contenu de 1' ouvrage est parfaitement a jour et couvre une large gamme de sujets. J2EE est 
un domaine tres actif, dans lequel les projets Open Source evoluent de maniere extremement 
rapide. Spring lui-meme a fortement progresse au cours des six derniers mois, pour atteindre 
sa version finahsee Spring 2.0. Les auteurs de ce livre ont accompli une veritable prouesse 
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pour traiter des fonctionnalites de cette version de Spring 2.0 des qu'elles ont pu etre stabilisees. 
La couverture de la technologie AJAX est en outre particulierement bienvenue. 

Pour finir, les auteurs ont fait F effort d'adjoindre au livre une application exemple realiste 
plutot qu'une etude de cas simpliste, comme on en trouve dans trop d'ouvrages. Cette appli- 
cation, Tudu Lists, est meme devenue un projet Open Source a part entiere, avec deja de 
nombreux utilisateurs. 

Ajoutons que le style d'ecriture est clair et pragmatique, rendant le parcours du lecteur tres 
agreable. 

Pour toutes ces raisons, je ne saurais trop recommander la lecture de cet ouvrage a ceux qui 
debutent dans l'utilisation du framework Spring ou qui souhaitent en approfondir la maitrise 
comme a ceux qui ont a cceur de mieux comprendre l'etat de l'art du developpement Java 
d'entreprise. 

Rod JOHNSON 

Founder, Spring Framework, CEO, SpringSource 
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Avant-propos 



Spring est un framework Open Source rendant l'utilisation de Java EE a la fois plus simple et 
plus productive. Tout au long de cet ouvrage, nous nous efforcons de degager les bonnes prati- 
ques de developpement d' applications Java/Java EE, dont une large part ne sont pas propres a 
Spring, mais dont la mise en ceuvre est grandement simplifiee et rendue plus consistante grace 
a son utilisation. 

Spring s'appuie sur des concepts modernes, tels que 1' inversion de controle ou la program- 
mation orientee aspect, ann d'ameliorer 1' architecture des applications Java/Java EE en les 
rendant plus souples, plus agiles et plus facilement testables. 

S'integrant avec les grands frameworks Open Source tels qu'Hibernate, ainsi qu'avec les stan- 
dards Java EE, Spring propose un modele d' application coherent, complet et simple d'emploi. 

Recommande par de nombreux architectes et developpeurs experimented, Spring commence a 
se diffuser au sein des SSII et des entreprises francaises. Une bonne connaissance de ce 
produit est done essentielle aujourd'hui, dans le monde tres concurrentiel de l'informatique 
d'entreprise. 

Objectifs de cet ouvrage 

Cet ouvrage se veut un guide pratique autour de Spring et de Fecosysteme technologique qui 
gravite autour. Spring ayant evolue et s'etant fortement etoffe ces dernieres annees, nous 
privilegions le cceur du modele de programmation introduit dans Spring 2.5, puis perpetue 
avec Spring 3.0, ainsi que Fenvironnement d'execution de SpringSource, qui s'appuie notamment 
sur OSGi. 

Nous avons voulu rendre ce livre accessible au plus grand nombre ann de permettre aux deve- 
loppeurs Java/Java Java EE d'etre plus productifs et de mieux reussir leurs projets a l'aide de 
Spring. C'est la raison pour laquelle nous n'entrons pas dans la description d' API complexes. 
II s'agit avant tout d'un ouvrage didactique, destine a rendre le lecteur directement operationnel. 

Cette volonte d'accessibilite ne signifie pas pour autant que F ouvrage soit d'une lecture 
simple et peu technique. Lorsque c'est necessaire, nous abordons des themes complexes, 
comme les transactions avec JTA ou F integration avec JCA. 
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Convaincus que Ton apprend mieux par la pratique, nous adjoignons a Fouvrage une etude de 
cas complete, 1' application Tudu Lists. Le lecteur a de la sorte sous les yeux, au fur et a 
mesure de sa progression, des exemples de mise en ceuvre concrete, dans une application 
reelle, des sujets traites. Quand le sujet principal d'un chapitre s'y prete, une etude de cas 
fondee sur Tudu Lists est decrite avec precision. 

Organisation de l'ouvrage 

L'ouvrage commence par decrire des principes et des problemes courants des applications 
Java/Java EE, puis aborde des concepts d' architecture logicielle tels que le developpement en 
couches ou les conteneurs legers. Cette introduction permet notamment d'etablir un vocabu- 
laire qui sera utilise tout au long des chapitres. 

L'ouvrage comporte ensuite cinq grandes parties : 

• La premiere partie presente de facon tres detaillee le cceur de Spring, c'est-a-dire son conte- 
neur leger et son framework de programmation orientee aspect. Les tests unitaires sont 
aussi abordes. 

• La partie II concerne la couche de presentation d'une application Web. Nous y presentons 
le framework Web Spring MVC ainsi que son complement Spring Web Flow. Nous passons 
aussi en revue des technologies AJAX s'interfacant avec Spring. 

• La partie III est dediee a la couche de persistance des donnees, essentiellement le mapping 
objet/relationnel, la gestion des transactions et les technologies JMS/JCA. 

• Une application ayant souvent besoin d'interagir avec d'autres systemes, la partie IV s'inte- 
resse aux technologies d'integration. L'integration peut etre realisee en Java, avec les techno- 
logies JCA ou JMS, mais egalement en XML, en particulier via des services Web. Cette 
partie aborde aussi la securite avec Spring Security et les traitements batch avec Spring 
Batch. 

• La partie V s'oriente vers les applications Spring lors de leur execution, avec le support de 
Spring pour OSGi, le serveur d' applications dm Server et le support JMX de Spring. 

A propos de I'applicationTudu Lists 

Lapplication Tudu Lists, qui nous sert d'etude de cas tout au long de l'ouvrage, est un 
exemple concret d'utilisation des technologies Spring. II s'agit d'un projet Open Source 
reel, qui a ete realise specifiquement pour cet ouvrage, et qui permet d'illustrer par l'exemple 
les techniques decrites dans chacun des chapitres. 

Loin de n'etre qu'un simple exemple, cette application est utilisee en production dans 
plusieurs entreprises. Le principal serveur Tudu Lists possede ainsi plus de cinq mille utilisateurs. 

Cette application etant Open Source, le lecteur est invite a participer a son developpement. 
Elle est disponible sur le site de l'ouvrage, a l'adresse http://www.springparlapratique.com. 
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Le code source utilise dans Fouvrage n'est pas directement issu de l'application de produc- 
tion, notamment pour des raisons pedagogiques. II est cependant disponible sur le site de 
Fouvrage. Toutes les instructions necessaires a Finstallation des projets des differents chapitres 
y sont decrites. Un forum permettant de poser des questions aux auteurs y est en outre propose. 

A qui s'adresse I'ouvrage ? 

Cet ouvrage s'adresse a tout developpeur Java/Java EE souhaitant ameliorer sa productivite et 
ses methodes de developpement et s'interessant a Farchitecture des applications. 

II n'est cependant nul besoin d'etre expert dans les differentes technologies presentees. 
Chaque chapitre expose clairement chacune d'elles, puis montre comment elle est implemen- 
tee dans Spring avant d'en donner des exemples de mise en ceuvre dans l'application Tudu 
Lists. 

Pour toute question, vous pouvez contacter les auteurs sur la page dediee a Fouvrage du site 
Web des editions Eyrolles, a Fadresse www.editions-eyrolles.com. 
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Ce chapitre a pour vocation de preciser le contexte du developpement d' applications d'entre- 
prises dans le monde Java, cela notamment pour expliquer quelle place le projet Spring 
occupe dans cette sphere vaste et complexe. Nous presenterons done l'edition entreprise de la 
plate-forme Java, a travers un bref historique et son mecanisme de standardisation. Cette 
presentation mettra en evidence les limites des outils standards de cette plateforme, nous 
veiTons alors comment le projet Spring parvient a les combler. Un ensemble de notions essen- 
tielles au modele de programmation de Spring seront ensuite abordees. Nous finirons par une 
mise en pratique de ces notions a travers la presentation de l'etude de cas Tudu Lists, utilisee 
comme fil conducteur dans cet ouvrage. 

Breve histoire de Java EE 

Java EE (Java Enterprise Edition) est une plate-forme fondee sur le langage Java et son envi- 
ronnement d' execution, qui regroupe un ensemble de technologies destinees a developper des 
applications d'entreprise. Ces applications ont la plupart du temps une composante serveur et 
sont concurrentes, e'est-a-dire qu'elles sont susceptibles d'etre accedees par plusieurs 
utilisateurs simultanement. 

La partie serveur est hebergee par un composant logiciel appele serveur d' applications, qui fournit 
une infrastructure d'execution aux applications. Un exemple d' infrastructure d'execution est le 
traitement de requetes HTTP : le serveur d' applications gere les entrees/sorties reseau et passe la 
main aux applications pour les traitements purement fonctionnels. Ce mode de fonctionnement 
permet aux applications de s'affranchir d'un certain nombre de problematiques techniques et 
de se concenter sur les parties metier, qui offrent une reelle plus-value pour l'utilisateur final. 

La gestion des requetes HTTP n'est qu'un exemple parmi un grand nombre de technologies 
prises en charge par les differentes briques de la plate-forme Java EE, qui propose un support pour 
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Faeces aux bases de donnees, l'envoi et la reception d'e-mails, la production et la consommation 
de services Web, etc. Ces technologies d'interfacage sont completees par d'autres technolo- 
gies correspondant a un modele de programmation : generation dynamique de code HTML 
(JSP/servlet), gestion transactionnelle (JTA), gestion de la persistance (JPA), etc. 

Java EE vise a fournir une infrastructure technique ainsi qu'un cadre de developpement pour 
les applications d'entreprise. 

Versions de Java EE 

La version entreprise de Java a vu le jour en 1999 sous le nom de J2EE 1 .2 (Java 2 Platform Enter- 
prise Edition). Sans entrer dans le detail de la logique de numerotation des versions de J2EE, 
sachons simplement que les versions 1.3 et 1.4 sont sorties respectivement en 2001 et 2003. 

Chacune de ces versions a apporte son lot de nouveautes technologiques, tout en amenant de 
nouvelles versions des technologies existantes. Les API Servlet et JSP sont certainement les 
plus connues de la pile J2EE, puisqu'elles constituent les solutions techniques de base pour 
les applications Web en Java. Les EJB (Enterprise JavaBeans), solution phare pour F imple- 
mentation de composants dits metiers, sont aussi Fun de piliers de J2EE. 

Si le modele theorique d'une application fondee sur J2EE etait des plus prometteurs, sa mise 
en pratique s'est averee tres difficile. Le modele proposait en effet un grand nombre de solutions, 
souvent surdimensionnees pour la grande majorite des projets. 

L'echec de projets fondes sur J2EE n'etait pas forcement du a la plate-forme elle-meme, mais 
plutot a la mauvaise utilisation des outils qu'elle fournissait. Cette mauvaise utilisation decou- 
lait generalement de la complexite de la plate-forme, dans laquelle se perdaient les equipes de 
developpement. 

Le symbole de la complexite de J2EE et de son inadequation aux besoins des applications 
d'entreprise s'incarne dans les EJB. Ces derniers disposaient d'atouts interessants, comme 
une gestion des transactions puissante et souple, mais qui s'accompagnaient invariablement 
d'inconvenients majeurs. Leur composante distribute etait, par exemple, un fardeau techno- 
logique, dont la plupart des applications pouvaient se passer. 

J2EE ne laisse cependant pas un constat d'echec definitif. De nombreuses briques se sont 
revelees parfaitement adaptees pour constituer le socle d' applications d'entreprise operation- 
nelles. Parmi ces briques, citons notamment Servlet et JSP, JavaMail, JMS (fonctionnement 
asynchrone) ou JTA (gestion des transactions). 

Ces briques n'ont pas ete les seules impliquees dans le succes des applications J2EE. 2004 a 
ete le temoin de F emergence d'un ensemble de solutions Open Source dont le but etait de 
pallier la complexite de J2EE et, surtout, de combler ses lacunes. Caracteristiques de ce 
courant, Hibernate et Spring ont fortement popularise le modele POJO (Plain Ordinary Java 
Object), qui rejetait le modele trop technologique des EJB. 

La nouvelle version de Fedition entreprise de Java, sortie en 2006, a su capturer Fessence du 
modele POJO et, forte de l'apport de Java 5, a propose un modele de programmation beaucoup 
plus pertinent que J2EE. Cette version a ete baptisee Java Enterprise Edition 5 (Java EE), afin de 
s' aligner sur la version 5 du langage. Java EE 5 se caracterise fortement par la simplification 
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en absorbant des principes du modele POJO, ail profit notamment des EJB (version 3) et de 
JPA (une API pour gerer la persistance des donnees). 

Java EE 6 continue le travail commence par Java EE, en proposant des fonctionnalites a la fois plus 
puissantes et plus simples pour les composants phares. La specification tend aussi a une modularite 
de la plate-forme, avec differents niveaux d' implementation des standards, qui permet de choisir 
exactement les composants necessaires selon ses besoins. Cette modularite concerne princi- 
palement les composants d' infrastructures, car les composants logiciels sont deja modulaires. 

Processus de standardisation de Java 

II existe un processus de standardisation de la plate-forme Java, appele Java Community 
Process (JCP). Ce processus concerne toute la plate-forme Java, pas juste l'edition entreprise. 
L'elaboration de Java EE passe done entierement par ce processus. Le JCP implique la crea- 
tion de requetes JSR (Java Specification Requests), qui constituent des propositions puis des 
realisations de certaines briques jugees necessaires a la plate-forme Java. Le processus de 
creation d'une JSR est bien sur tres formalise, avec notamment l'elaboration d'une specifica- 
tion sous la forme d'un document, sa validation par un jury dedie et l'ecriture d'une imple- 
mentation de reference (reference implementation ou RI), gratuite. 

Une JSR constitue done une specification, e'est-a-dire un standard, dans le monde Java. 
II s'agit bien d'une specification, e'est-a-dire la description d'un besoin de la plate-forme et la 
proposition d'un modele adressant le besoin. La proposition doit etre tres complete et tres 
precise, car elle est susceptible d'etre ensuite implemented par differents produits. Un autre 
livrable d'une JSR est d'ailleurs un kit de validation, permettant de s' assurer qu'un produit 
implemente correctement la specification. 

Toute personne peut etre partie prenante dans le JCP en proposant une JSR et meme en participant 
a l'elaboration d'une specification. Une JSR est elaboree par un groupe d' experts, qui comprend 
des experts reconnus dans le domaine concerne, independants ou affilies a des entreprises. 

Pour la plate-forme Java, la creation de standards assure une concurrence generalement 
constructive entre les implementations d'une JSR, basee en quelque sorte sur le principe de la 
selection naturelle. Le standard evite normalement aussi de se retrouver pieds et poings lies a un 
produit (s'il s'avere par exemple une implementation peu performante). C'est ce qu'on appelle le 
vendor lock-in. Cependant, dans les faits, le passage d'une implementation a une autre pour des 
systemes de grande faille se fait rarement sans douleur. Parmi les avantages des standards figure 
aussi l'interoperabilite, permettant a des systemes differents de communiquer. 

Si a travers la notion de standard, le JCP a des effets benefiques sur la plate-forme Java, il 
ne peut repondre a toutes les problematiques. Les groupes d'experts n'etant pas toujours 
independants, e'est-a-dire lies a des entreprises, des decisions d'ordre politique sont parfois 
prises au detriment de decisions d'ordre technique, plus judicieuses. Les groupes d'experts ou 
les comites impliques dans le JCP ne sont d'ailleurs pas toujours representatifs des commu- 
nautes d'utilisateurs. Cela peut donner lieu a des solutions inadaptees ou a un effet « tour 
d'ivoire » a cause de decisions prises en petit comite. 

De par sa nature, le JCP ne peut constituer un element reellement moteur dans l'innovation 
de la plate-forme Java. Bien que la competition entre implementations puisse contribuer a 
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F innovation, il faut qu'elle soit correctement equilibree, car Fabondance de solutions provo- 
que de la dispersion et peut faire ail final de Fombre aux meilleures solutions. Le JCP basant 
generalement ses specifications sur des solutions existantes, ayant innove dans un domaine, le 
caractere innovant est perdu a cause de Finertie du processus de standardisation. 

Si le JCP, a travers les standards, apporte beaucoup a la plate-forme Java, un ingredient 
supplementaire est necessaire, afin d'apporter la creativite et 1' experimentation neces- 
saries a Finnovation. Cet ingredient est generalement apporte par un ensemble d'acteurs, notam- 
ment FOpen Source, qui dispose d'une souplesse que le JCP n'a pas. On ne peut pas opposer 
FOpen Source et un processus de standardisation comme le JCP, car ils disposent chacun 
d'avantages et d'inconvenients, sont fortement lies et finalement complementaires. 

Problematiques des developpements Java EE 

Malgre une simplification progressive, la plate-forme Java reste complexe, demandant 
des connaissances techniques approfondies. En contrepartie, elle est d'une grande puissance et 
permet de repondre aux besoins des applications les plus ambitieuses. Developper des 
applications avec une approche 100 % Java EE revele cependant quatre faiblesses recurrentes : 

• Mauvaise separation des preoccupations : des problematiques d'ordres differents (technique 
et metier) sont mal isolees. Cependant, c'est certainement dans ce domaine que Java EE a 
fait le plus de progres depuis J2EE, notamment grace a des concepts popularises par des 
frameworks comme Spring. 

• Complexite : Java EE reste complexe, notamment a cause de la plethore de specifications 
disponibles. Les equipes de developpement n'ont pas d'angle d'attaque evident et se retrou- 
vent parfois noyees sous l'offre. L'exemple typique est un serveur d' applications monoli- 
thique, implementant la totalite de la specification Java EE, dont a peine 20 % sont 
necessaires pour developper la plupart des applications. 

• Mauvaise interoperabilite : malgre la notion de standard, les technologies ne sont pas 
toujours interoperables et portables. Une implementation JPA disposera toujours d' options 
differentes de ces consceurs et une application Web pourra rarement passer d'un serveur 
d' applications a un autre sans reglage supplementaire. 

• Mauvaise testabilite : les applications dependant fortement de F infrastructure d' execution, 
elles sont plus difficilement testables. C'est aussi une des consequences d'une mauvaise 
separation des preoccupations. 

En resume 

Ce bref historique de Java EE a mis en evidence les problematiques de cette plate-forme, notam- 
ment une certaine inadequation avec les besoins des developpements d' applications d'entreprise. 

Cependant, Java EE a su evoluer et s' adapter a travers ses differentes versions, et ce depuis dix 
ans. Cette evolution a passe par une instance de standardisation, le Java Community Process 
(JCP). Les standards ne sont toutefois pas suffisants pour qu'une plate-forme telle que Java 
EE soit performante et surtout innovante. L'Open Source peut etre un des acteurs de cette 
innovation en contribuant, grace a un JCP attentif et a l'ecoute, a F amelioration de Java EE. 
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Nous allons voir comment Spring a su comprendre les problemes lies a J2EE ann de proposer 
un modele de programmation plus adapte et plus productif. 

Java EE a su capter en partie l'apport de solutions telles que Spring et s' adapter dans une 
certaine mesure. Nous verrons les elements qui constituent l'ecosysteme de Spring et qui 
s'assemblent en une solution de developpement puissante et coherente. Nous verrons 
aussi l'histoire de Spring, a travers ses differentes versions et aborderons la plate-forme 
Spring, qui consiste en un serveur d' applications modulaire fonde sur la technologie 
OSGi. 

Les reponses de Spring 

Pour remedier aux problemes que nous venons d'evoquer, un ensemble de solutions a emerge. 
Nous allons explorer les reponses apportees par Spring aux problematiques du developpement 
d' applications d'entreprise dans le cadre d'une solution 100 % Java EE. 

La notion de conteneur leger 

Dans le monde Java, un conteneur leger est souvent oppose a un conteneur EJB, juge lourd 
technologiquement et surtout peu adaptatif par rapport aux differents types de problematiques 
courantes dans le monde des applications d'entreprise. 

Le conteneur leger fournit un support simple mais puissant pour gerer une application via un 
ensemble de composants, c'est-a-dire des objets presentant une interface, dont le fonctionne- 
ment interne n'a pas a etre connu des autres composants. Le conteneur leger gere le cycle de 
vie des composants (creation, destruction), mais aussi leurs interdependances (tel composant 
s'appuie sur tel autre pour fonctionner). 

Le conteneur leger permet d'avoir des applications plus portables, c'est-a-dire parfaitement 
independantes du serveur d' applications, car 1' application vient avec son propre conteneur, 
qui lui fournit 1' infrastructure dont elle a besoin. 

A travers son approche par composants, le conteneur leger encourage les bonnes pratiques de 
programmation : par interface, et a faible couplage. Cela assure une meilleure evolutivite des 
applications, mais aussi ameliore grandement leur testabilite. 

Le cceur de Spring est un conteneur leger, qui est aujourd'hui considere comme le plus 
complet sur le marche. 

La programmation orientee aspect 

La programmation orientee aspect (POA) est un paradigme de programmation qui consiste a 
modulariser des elements logiciels en complement d'approches telles que la programmation 
orientee objet. 

La POA se concentre sur les elements transversaux, c'est-a-dire ceux qui se trouvent dupli- 
ques ou utilises dans de nombreuses parties d'une application, sans pouvoir etre centralises 
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avec les concepts de programmation « classiques ». Des exemples d'elements transversaux 
sont la gestion des transactions, la journalisation ou la securite. La POA ameliore done 
nettement la separation des preoccupations dans une application. 

Spring propose depuis sa premiere version un excellent support pour la POA et a finalement 
contribue a sa popularisation. En effet, dans la mesure oil le conteneur leger de Spring 
controle le cycle de vie des composants d'une application, il peut leur ajouter du compor- 
tement (on parle aussi de decoration), et ce de facon completement transparente. 

Le support de la POA par Spring n'impose aucune contrainte et permet d'ajouter tres facilement 
du comportement a n'importe quel type d'objet. 

L'integration de frameworks tiers 

Spring propose une integration pour un grand nombre de frameworks et de standards Java EE. 
Lintegration passe generalement par un support pour la configuration dans le conteneur leger, 
mais aussi par des classes d' abstraction. 

Spring offrant une grande coherence, les frameworks sont generalement integres de maniere 
similaire, ce qui facilite Fassimilation et le passage de Tun a l'autre. Spring laisse aussi 
toujours la possibilite d'utiliser l'API native des frameworks, car il se veut « non intrusif ». 
II est important de noter que Spring ne limite jamais les possibilites d'un framework en raison 
de 1'integration qu'il propose. 

Un exemple caracteristique de cette integration est le support d' Hibernate propose par Spring. 
Une partie de la configuration d' Hibernate est automatiquement prise en charge, et la gestion 
des ressources (connexion a la base de donnees, transactions), contraignante et propice a des 
erreurs de programmation, est faite par les classes de support de Spring. 

L'ecosysteme Spring 

Spring est maintenant plus qu'un conteneur leger, utilise pour le developpement d'applica- 
tions d'entreprise. II constitue le socle de nombreux projets (le portfolio Spring) et la base 
technique d'un serveur d' applications. 

La figure 1-1 illustre les differentes briques du projet Spring, avec notamment l'integration 
proposee pour certains frameworks. 



Figure 1-1 
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Le projet Spring est constitue des modules suivants : 

• Core, le noyau, qui contient a la fois un ensemble de classes utilisees par toutes les briques 
du framework et le conteneur leger. 

• AOP, le module de programmation orientee aspect, qui s'integre forte ment avec Aspect J, un 
framework de POA a part entiere. 

• DAO, qui constitue le socle de Faeces aux depots de donnees, avec notamment une imple- 
mentation pour JDBC. D'autres modules fournissent des abstractions pour l'acces aux 
donnees (solutions de mapping objet-relationnel, LDAP) qui suivent les memes principes 
que le support JDBC. La solution de gestion des transactions de Spring fait aussi partie de 
ce module. 

• ORM, qui propose une integration avec des outils populates de mapping objet-relationnel, 
tels que Hibernate, JPA, EclipseLink ou iBatis. Chaque outil peut beneficier de la gestion 
des transactions fournie par le module DAO. 

• Java EE, un module d'integration d'un ensemble de solutions populaires dans le monde de 
l'entreprise. 

• Web, le module comprenant le support de Spring pour les applications Web. II contient 
notamment Spring Web MVC, la solution de Spring pour les applications Web, et propose 
une integration avec de nombreux frameworks Web et des technologies de vue. 

• Test, qui permet d'appliquer certaines techniques du conteneur leger Spring aux tests 
unitaires via une integration avec JUnit et TestNG. 

Les aspects cles de ces modules sont abordes dans les differents chapitres de cet ouvrage. 
Les projets du portfolio 

Un ensemble de projets gravitent autour de Spring, utilisant le conteneur leger et ses modules 
comme bases techniques et conceptuelles : 

• Spring Web Flow. Propose un support pour gerer des enchainements de pages complexes 
dans une application. 

• Spring Web Services. Apporte un support pour les services Web, avec une approche 
contract-first. 

• Spring Security. Permet de gerer Tauthentification et l'autorisation dans une application 
Web, en promouvant une approche transverse et declarative. 

• Spring Dynamic Modules. Facilite l'integration des applications d'entreprise sur la plate- 
forme OSGi, afin de pousser le modele de composant jusque dans Fenvironnement 
d' execution. 

• Spring Batch. Propose un support pour les traitements de type batch, manipulant de grands 
volumes de donnees. 

• Spring Integration. Implementation des Enterprise Integration Patterns, qui apportent une 
dimension evenementielle a une application Spring et lui permettent d'interagir avec des 
systemes externes grace a des connecteurs. 
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• Spring LDAP. Implemente F approche de gestion des acces aux donnees de Spring pour les 
annuaires LDAP. 

• Spring IDE. Ensemble de plug-ins Eclipse facilitant l'edition de configurations Spring. 

• Spring Modules. Propose une integration dans Spring de differents outils et frameworks. 

• Spring JavaConfig. Implemente une approche Java pour la configuration de contextes 
Spring. 

L' ensemble de ces projets font de Spring une solution pertinente pour tout type de develop- 
pement sur la plate-forme Java. 

Traiter de 1' ensemble de ces projets necessiterait beaucoup plus qu'un simple ouvrage. Nous 
nous contenterons done de couvrir les aspects fondamentaux de ceux parmi ceux les plus utilises 
dans le monde de Fentreprise. 

Versions de Spring 

Quand la premiere version de Spring est sortie, en 2004, elle contenait deja toutes les briques 
de base de Spring, notamment son conteneur leger. Cependant la configuration XML etait tres 
generique et ne laissait que peu de place a Fextensibilite. 

La version 2.0, sortie en octobre 2006, a revu de fond en comble le systeme de configuration 
XML, avec la notion de schema. Cette nouveaute rendait la configuration beaucoup moins 
verbeuse, et surtout plus explicite. Elle ouvrait aussi des possibilites d'extensibilite, puisque 
n'importe quel systeme pouvait definir son propre schema de configuration et beneficier de la 
puissance du conteneur leger. 

Cette version proposait en outre les premieres annotations, destinees a completer la configu- 
ration XML. Spring 2.0 voyait enfin son systeme de POA s'integrer tres etroitement avec le 
framework AspectJ. 

Spring 2.5, sorti en novembre 2007, a pousse encore plus loin la configuration par annota- 
tions, aussi bien pour Finjection de dependances que pour la declaration de composants. Les 
annotations ont aussi ete introduites dans Spring Web MVC, afin de faciliter la configuration 
des controleurs. 

Spring 3.0 apporte son lot de nouveautes, avec notamment un support de REST (Representa- 
tional State Transfer), un langage d'expression destine a faciliter la configuration, et un 
modele declaratif de validation. 

Spring 3.0 consiste surtout en une refonte complete du noyau, qui se conformait auparavant a 
Java 1.4, afin d'utiliser pleinement Java 5. Depuis Spring 2.0, des fonctionnalites necessitant 
Java 5 avaient ete ajoutees, mais le noyau de Spring etait toujours fonde exclusivement sur 
Java 1.4, principalement pour des besoins de compatibilite. 

Spring 3.0 effectue egalement un nettoyage de parties depreciees, mais jusque-la toujours 
presentes. Enfin, la documentation de reference est allegee et se concentre sur les fonction- 
nalites introduites depuis Spring 2.5. 

Pour le developpeur, la difference entre les versions 2.5 et 3.0 est mineure, puisque le modele 
de programmation reste completement compatible. La migration n'est cependant pas inutile, 
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car des classes au cceur de Spring profitent pleinement des possibilites de Java 5, comme les 
generiques, rendant ainsi la programmation plus simple et plus fiable. 

Du developpement a I'execution 

Le projet Spring, a travers son conteneur leger et un ensemble de pratiques, comme la 
programmation par interface, a toujours prone un modele de composants. 

Voici les criteres communement admis pour definir un composant : 

• Existence d'un contrat (interface) : pour pouvoir communiquer avec le composant. 

• Dependances explicites : les autres composants, sur lesquels s'appuie un composant pour 
fonctionner, doivent etre connus et identifies. 

• Deploiement independant : un composant doit pouvoir etre deploye de facon autonome, 
sans faire partie d'un systeme monolithique. 

• Composition avec d' autres composants possibles : un ensemble de composants doivent 
pouvoir etre combines pour fournir des services complexes, et pas seulement unitaires. 

Un des apports de l'approche par composant est sa forte reutilisabilite. Si Spring facilite une 
telle approche par son modele de programmation, il est cependant limite pour pousser ce 
modele jusqu'a l'environnement d'execution. 

En effet, a travers son systeme de packaging (war, ear), Java EE propose un modele de compo- 
sants d'assez forte granularite, dans lequel l'unite est l'application, plutot que le composant. 
Le critere de deploiement independant n'etant pas satisfait, les composants restent des entites 
conceptuelles, grace notamment aux possibilites objet du langage Java, mais ne peuvent 
pretendre a cette souplesse en pleine execution. 

La communaute Spring, a travers la societe SpringSource, a decide de pousser le modele de 
composants jusque dans I'execution des applications d'entreprise Java. Elle s'est appuyee 
pour cela sur la technologie OSGi, qui propose un modele de composants dynamiques, permettant 
notamment de deployer et meme de mettre a jour des composants dynamiquement. 

La technologie OSGi etait au depart dediee au monde de l'embarque, mais elle a connu un 
renouveau en se retrouvant introduite dans le monde de l'application d'entreprise. Si elle 
commence a etre populaire (au point servir de base d' infrastructures logicielles telles que les 
serveurs d' applications), le pari de SpringSource est de l'amener jusque dans les applications 
elles-memes. 

C'est pour relever ce defi que les projets Spring Dynamic Modules et dm Server ont vu le jour. 
Spring Dynamic Modules est un des pivots du serveur d' applications modulaire dm Server. Si 
celui-ci est fonde sur un ensemble de technologies existantes (OSGi, Tomcat, AspectJ, 
Spring), la difficulte n'en est pas moindre, tant leur cohabitation est des plus complexes, 
certaines de ces technologies n'etant pas prevues pour fonctionner dans le monde des 
applications d'entreprise. 

Les premieres applications modulaires tournant sous dm Server ont vu le jour en 2008, revolu- 
tionnant le deploiement d' applications d'entreprise du monde Java. Les applications peuvent 
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en effet des lors etre decomposers en un ensemble de modules totalement independants du 
point de vue du deploiement et pouvant faire l'objet de mises a jour dynamiques, sans provo- 
quer 1'arrSt de l'application. 

Les projets Spring Dynamic Modules et dm Server sont abordes en detail respectivement aux 
chapitres 16 et 17. 

En resume 

Grace a son conteneur leger, a son approche pragmatique de la programmation orientee aspect 
et a F integration de nombreux frameworks tiers, a su combler certaines lacunes de Java EE et 
contribuer a son amelioration. 

Spring repond particulierement bien aux besoins des applications d'entreprise de par son 
approche modulaire, son support de nombreuses technologies et son cote peu intrusif (le code 
applicatif ne depend pas des API Spring). De plus, le portfolio Spring contient des projets 
completant le framework de base, destines a adresser les differentes problematiques qu'on 
retrouve dans les applications d'entreprise. 

Depuis peu, le modele de composants prone par Spring peut etre applique jusque dans l'envi- 
ronnement d' execution, grace a dm Server, ce qui augure de perspectives interessantes pour la 
plate -forme Java. 

Notions d'architecture logicielle 

Cette section introduit des motifs de conception frequemment utilises dans les applications 
d'entreprise, telles l'inversion de controle et l'injection de dependances. Forts de la connais- 
sance de ces motifs, nous pourrons aborder l'utilite d'un conteneur leger dans une application. 

Ces notions constituent les bases conceptuelles de F etude de cas Tudu Lists. Leur bonne 
maitrise aidera done aussi a la comprehension des exemples de cet ouvrage, tires de Tudu 
Lists pour la plupart. 

Couches logicielles 

Dans le developpement logiciel, la division en couches est une technique repandue pour 
decomposer logiquement un systeme complexe. II ne s'agit d'ailleurs pas d'une technique 
propre au developpement informatique, puisqu'on la retrouve dans l'architecture des ordinateurs 
et dans les reseaux (couches OSI). 

La decomposition en couches revient a modeliser un systeme en un arrangement vertical de 
couches. Chaque couche constitue l'une des parties du systeme : en tant que telle, elle a des 
responsabilites et s'appuie sur la couche immediatement inferieure. 

La communication entre couches suit des regies tres strictes : une couche ne connait que la 
couche inferieure et ne doit jamais faire reference a la couche superieure (elle ignore 
d'ailleurs completement son existence). En Java (ou en termes de langage objet), la 
communication entre couches s'effectue en etablissant des contrats via des interfaces. La 
notion de dependance, quant a elle, se caracterise par des instructions d'import de packages. 
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Decomposer un systeme en couches presente de nombreux avantages, notamment les suivants : 

• possibilite d'isoler une couche, afin de faciliter sa comprehension et son developpement ; 

• tres bonne gestion des dependances ; 

• possibilite de substituer les implementations de couches ; 

• reutilisation facilitee ; 

• testabilite favorisee (grace a Fisolement et a la possibilite de substituer les implementations). 

Ces avantages expliquent pourquoi la decomposition en couches est abondamment utilisee 
dans le developpement logiciel. 

Elle ne va toutefois pas sans quelques inconvenients, notamment les suivants : 

• L'independance totale des couches est souvent difficile a atteindre. Modifier une couche 
peut done necessiter des modifications en cascade. 

• Un systeme trop decompose peut s'averer difficile a apprehender conceptuellement. 

• Une succession de couches peut avoir un effet negatif sur les performances, par rapport a un 
traitement direct. 

La difficulte d'une decomposition en couches est d'identifier les couches du systeme, e'est-a- 
dire d'etablir leurs responsabilites respectives et leur facon de communiquer. 

Dans les systemes client-serveur populaires dans les annees 1990, les couches etaient au 
nombre de deux : l'une de presentation, contenant aussi des traitements metier, F autre de 
donnees, generalement une base de donnees. Avec Favenement du Web et des clients legers, 
les systemes ont ete decomposes en trois couches : presentation (client leger), traitements 
(serveur) et donnees (base de donnees). 

Le modele a trois couches est suffisamment explicite pour comprendre les concepts d'un 
decoupage logique, mais aussi physique. Nous lui preferons cependant un modele a cinq 
couches, centre sur le developpement logiciel, que nous utiliserons tout le long de cet 
ouvrage. Ce modele est illustre a la figure 1-2, avec, a titre d'exemple, des technologies ou 
frameworks associes aux differentes couches. 



Figure 1-2 

Modele a cinq couches et 
technologies associees 



Presentation 

JSP, moteurs de templates.. 



Coordination 

Spring WebMVC, JSF, Struts... 



Metier 

POJO, Moteurs de regies.. 



Acces aux donnees 

JDBC, Hibernate, JPA... 



Persi stance 

Base de donnees , annuaire LDAP .. 
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Le tableau 1-1 recense les fonctions de ces differentes couches, ainsi que les noms communement 
adoptes pour les composants qui les constituent. 



Tableau 1-1. Fonction des couches 



Norn 


Fonction 


Composant 


Presentation 


Gestion du code de presentation de I'interfaoe utilisateur 


Vue 


Coordination 


Analyse des requetes utilisateur, orchestration des appels metier, 
gestion de la cinematique 


Controleur 


Metier 


Implementation des regies fonctionnelles d'une application 


Service 


Acces aux donnees 


Interaction avec I'entrepot de donnees (recuperation, mise a jour, etc.) 


Data Access Object (DAO) 


Persistance 


Stockage des donnees 


Entrepot de donnees 



Ce modele en couches souleve deux questions. La premiere concerne la gestion des transac- 
tions et la securite. Ces dernieres peuvent en fait etre gerees directement par certaines couches 
(la base de donnees, par exemple, est capable de gerer des transactions, pour peu qu'une des 
couches se charge de les demarquer) ou par le biais de la programmation orientee aspect — 
puisqu'il s'agit la de problematiques transverses. 

La seconde difficulte concerne l'utilite de Spring dans un tel modele. Spring est en realite 
capable d'intervenir au niveau de chacune des couches, grace notamment au support qu'il 
propose pour de nombreux frameworks ou technologies utilises dans les diverses couches 
ou via la programmation orientee aspect. Spring propose, par exemple, un systeme de 
gestion des transactions a la fois puissant, portable et particulierement interessant, car 
declaratif. 

Comme indique precedemment, dans un langage oriente objet tel que Java, le contrat de 
communication entre les couches s'effectue grace a la notion d'interface. Les couches metier 
et d' acces aux donnees ne sont connues que par les interfaces qu'elles exposent, comme le 
montre la figure 1-3. 



Figure 1-3 

Communication 
intercouche par le biais 
des interfaces 



P 
Q 



Presentation 

Vues 



Coordination 

Controleurs 



Interfaces des services 



Metier 

Implementations des services 





Interfaces des DAO 






Acces aux donnees 






Implementations des DAO 




Persistance 
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Cette figure illustre une couche qui ne suit pas les regies enoncees jusqu'ici : la couche 
domaine, qui contient les classes representant les entites metier manipulees dans F application. 
Pour une application telle que Tudu Lists, il s'agit des Todos et des listes de Todos. Pour une 
application gerant une boutique en ligne, il s'agit d'articles, de commandes, de factures, etc. 

Les entites sont stockees en base de donnees, avec generalement une correspondance classe- 
table et propriete-colonne. Les objets de la couche domaine transitent a travers les couches — 
ce qui est tout a fait normal, puisqu'ils represented des notions communes a toute une appli- 
cation. En effet, chacune des couches est amenee a manipuler ces classes. 

Dans une application Spring, Fensemble des composants (controleurs, services et DAO) sont 
geres par le conteneur leger. Celui-ci se charge de leur cycle de vie, ainsi que de leurs inter- 
dependances. Nous verrons ci-apres les concepts sous-jacents a la gestion des dependances. 

Grace a la POA, ces composants peuvent aussi etre decores, c'est-a-dire que des operations 
telles que la gestion des transactions peuvent leur etre ajoutees, et ce de facon transparente. 

La programmation par interface 

La programmation par interface est une notion relativement simple de la programmation 
orientee objet. Nous en rappelons dans cette section les principes et benefices. 

Dans le modele a cinq couches que nous avons presente, les services metier se fondent sur des 
DAO pour communiquer avec F entrepot de donnees, generalement une base de donnees. 

Chaque service metier contient des references vers des objets d'acces aux donnees. 

La figure 1-4 illustre les dependances d'un service metier de Tudu Lists, UserManagerlmpl, a 
l'egard d'un DAO. 



Figure 1-4 

Dependances entre un 
service metier et un DAO 
(couplage fort) 



UserManagerl mpl 




UserDAOJpa 




■ > 

1 1 









Le service metier depend fortement de F implementation du DAO, d'ou un couplage fort. Pour 
reduire ce couplage, il est non seulement necessaire de definir une interface pour le DAO, 
mais que le service se repose sur celle-ci. C'est ce qu'illustre la figure 1-5. 



Figure 1-5 

Ajout d'une interface entre 
le sendee et le DAO 
(couplage laclxe) 



UserManagerl mpl 


> 


« interface» 
UserDAO 




1 1 







5" 



UserDAOJpa 



L introduction d'une interface pour le DAO permet de decoupler le service de l'implementa- 
tion du DAO. L'interface definit le contrat de communication, tandis que F implementation du 
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DAO le remplit : le service pourra done l'utiliser, que la technologie de persistance sous- 
jacente soit JPA ou Hibernate. 

La programmation par interface est un principe a suivre dans toute application, et pas simple- 
ment pour les couches d'une application d'entreprise. Si nous prenons l'exemple des struc- 
tures de donnees en Java, sachant que la classe java.util .ArrayList implemente l'interface 
java . uti 1 . Li st, le listing suivant illustre les deux modelisations vues precedemment : 

ArrayList 11 = new ArrayListO; // couplage fort 
List 12 = new ArrayListO; // couplage lache 

La variable 1 2 peut utiliser n'importe quelle implementation de Li st, alors que 1 1 est liee par 
sa declaration a Array Li st. Si, pour une variable locale, ce decouplage n'est pas primordial, il 
Test en revanche dans les signatures de methodes, dont les types de retours et les parametres 
doivent etre des interfaces (dans la mesure du possible). 

L'inversion de contrdle 

Les conteneurs legers sont sou vent appeles conteneurs d' inversion de controle, ou IoC (Inver- 
sion of Control). Nous allons voir Forigine de ce concept et dans quelle mesure il se rapproche 
de la notion de conteneur leger. 

Controle du flot a" execution 

Dans l'inversion de controle, le controle fait reference au flot d'execution d'une application. 
Dans un style de programmation procedural, nous controlons totalement le flot d'execution du 
programme, via des instructions, des conditions et des boucles. 

Si nous considerons une application utilisant Swing (l'API graphique standard de Java), par 
exemple, nous ne pouvons pas dire que le flot d'execution est maitrise de bout en bout par 
F application. En effet, Swing utilise un modele evenementiel qui declenche les traitements de 
l'application en fonction des interactions de l'utilisateur avec 1'IHM (clic sur un bouton, etc.). 

En nous reposant sur Swing pour declencher les traitements de l'application, nous operons 
une inversion du controle du flot d'execution, puisque ce n'est plus notre programme qui se 
charge de le controler de bout en bout. Au contraire, le programme s'insere dans le cadre de 
fonctionnement de Swing (son modele evenementiel) en « attachant » ses differents traitements 
aux evenements generes par Swing suite aux actions de l'utilisateur. 



IoC, frameworks et bibliotheques logicielles 

Comme I'a fait remarquer Martin Fowler dans un article sur les conteneurs, l'inversion de controle est un 
principe qui permet de distinguer les frameworks des bibliotheques logicielles. Les bibliotheques sont de 
simples boites a outils, dont les fonctions s'inserent dans le flot d'execution du programme. II n'y a done 
pas d'inversion de controle. A I'inverse, les frameworks prennent a leur charge I'essentiel du flot d'execution 
dans leur domaine de specialite, le programme devant s'inserer dans le cadre qu'ils determined. 



Le concept d'inversion de controle est au moins aussi ancien que celui de programmation 
evenementielle. II releve d'un principe generique utilise par de nombreux frameworks apparus 
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bien avant la notion de conteneur leger. L'inversion de controle est aussi appelee « principe 
Hollywood » en reference a la phrase mythique « ne nous appelez pas, nous vous appellerons ». 

Les frameworks Web tels que Spring Web MVC ou Struts implemented une inversion de 
controle puisqu'ils se chargent d'appeler eux-memes les controleurs de Fapplication en fonction 
des requetes envoyees par les navigateurs Web. 

L'inversion de controle dans les conteneurs legers 

Les conteneurs legers proposent une version specialisee de l'inversion de controle. lis visent a 
resoudre les problematiques d'instanciation et de dependances entre les composants d'une 
application. 

Dans notre exemple de service metier de Tudu Lists, celui-ci a une dependance vers un DAO. 
A l'aide d'un raisonnement par interface, nous avons reussi a reduire le couplage, mais 
l'initialisation des deux composants (le service et le DAO) peut s'averer complexe. Le service 
pourrait s'occuper de l'instanciation du DAO, mais il serait alors lie a son implementation. 
Nous perdrions le benefice du raisonnement par interface. De plus, l'initialisation du DAO 
peut s'averer complexe, puisqu'elle implique la connexion a une base de donnees. 

Une autre solution consisterait a utiliser une fabrique, c'est-a-dire un objet qui serait capable de 
fournir au service le DAO. Cette fabrique s'occuperait de l'initialisation du DAO pour foumir une 
instance prete a l'emploi. Le service demanderait explicitement le DAO a la fabrique. 

Dans les deux cas (instanciation par le service ou utilisation d'une fabrique), le service joue 
un role actif dans la recuperation de sa dependance. Les conteneurs legers proposent un mode 
de fonctionnement inverse, dans lequel le service n'a rien a faire pour recuperer sa depen- 
dance. Le conteneur leger gere aussi la creation du service et du DAO, ainsi que F injection du 
DAO dans le service. 

L'injection de dependances 

Dans son principe, l'injection de dependances s'appuie sur un objet assembleur — le conte- 
neur leger — , capable de gerer le cycle de vie des composants d'une application, ainsi que 
leurs dependances, en les injectant de maniere appropriee. 

Dans notre exemple, le service et 1' implementation correcte du DAO se voient instancies, et le 
DAO est injecte dans le service. De cette maniere, le service n'effectue aucune action ou 
requete explicite pour recuperer sa dependance 

II existe differents moyens d'effectuer de l'injection de dependances. Spring utilise l'injection 
par constructeur (un objet se voit injecter ses dependances au moment ou il est cree, c'est-a- 
dire via les arguments de son constructeur) et l'injection par modificateurs (un objet est cree, 
puis ses dependances lui sont injectees par les modificateurs correspondants). Les deux 
formes ne sont pas exclusives, et il est possible de les combiner. 

Grace a l'injection de dependances, les composants sont plus independants de leur environne- 
ment d' execution. lis n'ont pas a se soucier de l'instanciation de leurs dependances et peuvent 
se concentrer sur leur tache principale. De plus, l'injection de dependances mettant en jeu le 
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conteneur leger, c'est lui qui gere toutes les problematiques de configuration, facilitant, par 
exemple, l'externalisation de parametres. 



Vers une standardisation de I'injection de dependances ? 

La JSR-299 (Java Contexts and Dependency Injection, autrefois nommee Web Beans) propose un modele 
de composants utilisant notamment I'injection de dependances. Elle peut done etre vue comme une standar- 
disation de cette notion dans le monde Java. Cette JSR a une longue histoire (elle a debute en 2006) et a fait 
I'objet de serieux changements. Elle devait etre incluse dans Java EE 6, mais, a I'heure ou ces lignes sont 
ecrites, sa place a ete remise en cause, et seul I'avenir nous dira si elle en fera veritablement partie. II n'est 
pas prevu pour I'instant que Spring implements un jour cette specification. Si les deux projets ont certains 
points communs, voire s'inspirent I'un I'autre, ils suivront vraisemblablement des chemins differents. 



L'injection de dependances met en jeu un referentiel de description des dependances. Avec 
Spring, sa forme la plus connue est XML, mais il est possible d'utiliser d'autres formes, 
comme de simples fichiers texte ou meme du Java. L'essentiel est de disposer au final d'un 
objet contenant tous les composants d'une application correctement initialises. 

Le conteneur leger dans une application 

Nous avons vu que I'injection de dependances etait fortement liee a la notion de conteneur. 
Une application doit done se reposer sur les mecanismes d'un conteneur leger pour la gestion 
de ses composants. 

La figure 1-6 illustre une application organisee sous forme de composants geres par un 
conteneur leger. 



Les composants de la figure 1-6 (representes par les petits ronds) peuvent avoir plusieurs 
origines : Java EE, Java ou les classes de F application. Ils sont geres par le conteneur leger 
(represente par le rectangle englobant) et forment ensemble un systeme coherent, F application. 
Les traits represented les dependances entre composants. 

Dans le cas d'une approche orientee service, l'application peut exposer certains de ses 
composants (partie superieure) a destination de consommateurs interesses par ces services. 
Cette exposition peut se faire grace notamment a des services techniques offerts par le 
conteneur leger. 



Figure 1-6 

Composants 

d'une application au sein 
d'un conteneur leger 




Vue externe de I'applicatior 



O Objet Java 



Java 
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La figure 1-7 correspond a un zoom de la precedente : elle illustre les composants ail sein des 
couches metier et d'acces aux donnees. 



Figure 1-7 

Composants de la couche 
metier d'acces aux donnees 




Couche metier 



Couche d'acces au donnees 



CD' 



I I DAO 



Le conteneur leger a done un controle total sur les composants de 1' application. Voici les differents 
niveaux selon lesquels peut se decomposer ce controle : 

• Cycle de vie. Les composants etant crees par le conteneur, ce dernier peut controler les 
parametres de configuration ainsi que toute sequence d' initialisation. Ce controle s'etend 
jusqu'a la destruction du composant, pour, par exemple, liberer des ressources. 

• Nature. La nature du composant peut etre vue comme le contexte dans lequel il est utilise. 
II peut, par exemple, etre global a F application (on parle de singleton) ou specifique a la 
requete en cours. Dans le vocabulaire des conteneurs legers, on parle aussi de portee. 

• Decoration. II est possible de demander au conteneur de decorer un composant, e'est-a- 
dire de lui ajouter du comportement. Un composant tout a fait ordinaire lors de son ecriture 
peut ainsi devenir transactionnel lors de F execution, et ce de facon transparente. 

• Publication d'evenements. Les composants faisant partie d'un systeme, ils peuvent etre 
prevenus d'evenements survenant en son sein. II s'agit d'un premier pas vers une program- 
mation evenementielle, favorisant le decouplage entre composants. 

• Infrastructure. Le conteneur, comme un serveur d' applications, peut fournir une infras- 
tructure, generalement grace a des composants purement techniques. Ces services peuvent 
etre, par exemple, un pool de connexions ou meme un gestionnaire de transactions. 



En resume 

Nous avons aborde dans cette partie des motifs de conception frequemment utilises dans les 
applications d'entreprise. Le decoupage en couches, notamment, permet une meilleure sepa- 
ration des preoccupations dans une application. II s'appuie sur la programmation par inter- 
face, qui est essentielle pour decoupler les couches entre elles. 

L'inversion de controle, souvent associee aux conteneurs legers, est en fait un concept assez 
ancien. Dans notre cas, il consiste a inverser la maniere dont les composants d'une application 
recuperent leurs dependances. 

L'injection de dependances est le veritable motif de conception implemente par le conteneur 
leger de Spring. Son principe est simple, mais il doit pour fonctionner s'appuyer sur des 
mecanismes fournis par un assembleur, le conteneur leger, qui gere les composants de leur 
creation a leur destruction. 
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L etude de cas Tudu Lists 



Tout au long de cet ouvrage, nous illustrons notre propos au moyen d'une application, Tudu 
Lists, faisant office d'etude de cas. 

Cette application n'est pas realisee pas a pas, car cela limiterait invariablement la couverture des 
fonctionnalites de Spring. Elle n'est la qu'a titre de fil conducteur le plus realiste possible. 

Comme indique dans l'avant-propos, 1' ensemble du code source de Tudu Lists, ainsi que les 
instructions d' installation sous Eclipse, sont accessibles a partir du site Web du livre. 

Presentation de Tudu Lists 

Tudu Lists est un projet Open Source cree par Julien Dubois et heberge chez SourceForge. 
Ce projet consiste en un systeme de gestion de listes de choses a faire (todo lists) sur le 
Web. II perniet de partager des listes entre plusieurs utilisateurs et supporte le protocole RSS 
(Really Simple Syndication). 

Les listes de choses a faire sont des outils de gestion de projet simples, mais efficaces. La 
version de Tudu Lists utilisee dans le contexte de cet ouvrage n'est qu'une branche de la 
version de production, concue a des fins principalement pedagogiques. Le code source appli- 
catif est cependant exactement le meme. Les modifications les plus importantes touchent 
surtout le packaging et l'organisation du projet et de ses modules. 

Lutilisation de Tudu Lists est d'une grande simplicite. La page d'accueil se presente de la 
maniere illustree a la figure 1-8. 

Figure 1-8 Welcome Register 

Page d'accueil Tudu 1,313 



de Tudu Lists 



Welcome to Tudu Lists! 



Tudu Lists is an on-line application for managing 
todo lists- 



Login 



Login : 



Tudu Lists is a very simple application, which you 
can start using in seconds but with some 
advantages over your home-made Excel todo list- 



Password : 



Remember me on this computer 
(30 days) □ 



Tudu Lists is web-based, and accessible 
from anywhere on the planet. 



Tudu Usts con be shored omongst people: 

yon ran shnrp lists with yniir fh^nds, 
family or co-workers. 



| Leg n ^e5r! 



Tudu Lists can be accessed with an RSS 
feed: if one of your shared lists is updated, 
your RSS aggregator will warn you. 



You ore not o ludu Lists user yet.' 
Just register. It's completely free. 



Tudu I isis t\ i omplHlfly frHH' lust 

register and start using it. 



Did you forget your password / Dick 
here to recover it. 



Cven Tudu Lists' source code is free! If 
yuu Wrftil yuui vuiy uwn ttisldll uf Tudu 

Lists, or if you are a programmer and want 

lu liuw Tudu Ltelb t* J- ■=■■_■.. r ■-- : ju*L 

visit our dcvclopcment Web site 
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Pour creer un nouvel utilisateur, il suffit de cliquer sur le lien « register » et de remplir le 
formulaire. Une fois authentifie, l'utilisateur peut gerer ses listes de todos. 

Par commodite, nous utiliserons a partir de maintenant le temie « Todo » pour designer une 
chose a faire (voir figure 1-9). 



My info My Todo Lists My Todos Log out 
Tudu Lists 



[ Refresh ] 
Welcome! fO/11 





Welcome! 






[ Add a new Todo ] 








Description 




ompteted Actions 


| Welcome to Tudu Lists! 


100 


□ [ Edit | Delete ] | 




Backupj* | Restore ♦ 





Figure 1-9 

Liste de Todos 



Par le biais des onglets disposes en haut de la page, nous pouvons gerer notre compte (My 
info), nos listes de Todos (My Todo Lists), nos Todos (My Todos) ou nous deloguer (Log out). 

La creation d'une liste est on ne peut plus simple. II suffit de cliquer sur l'onglet My Todo 
Lists puis sur le lien Add a new Todo List et de remplir le formulaire et cliquer sur le lien 
Submit, comme illustre a la figure 1-10. 



Figure 1-10 

Creation d'une liste 
de Todos 



Ad 



d a new Todo List 



Description [ 

Allow RSS _ 
publlcatlon? 

[ Submit ] ( Cancel ] 



La creation d'un Todo suit le meme principe. Dans l'onglet My Todos, il suffit de cliquer sur 
la liste dans laquelle nous souhaitons ajouter un Todo (les listes sont affichees dans la partie 
gauche de la page) puis de cliquer sur Add a new Todo. 

Nous pouvons sauvegarder le contenu d'une liste en cliquant sur le lien Backup. De meme, 
nous pouvons restaurer le contenu d'une liste en cliquant sur le lien Restore. 



Architecture de Tudu Lists 

Tudu Lists est une application Web concue pour demontrer que F utilisation de Spring et de 
frameworks specialises permet d'obtenir, sans developpement lourd, une application corres- 
pondant a Fetat de Fart en termes de technologie. 
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Dans cette section, nous decrivons de maniere synthetique les principes architecturaux de 
Tudu Lists. Ces informations seront utiles pour manipuler l'etude de cas tout au long 
de l'ouvrage. 

Les technologies utilisees 

Outre Spring, Tudu Lists utilise les technologies suivantes : 

• JPA pour la persistance des donnees, avec comme implementation Hibernate. 

• Spring MVC pour la partie Web. 

• DWR (Direct Web Remoting) pour implementer les fonctionnalites Ajax. 

• Spring Security pour gerer l'authentification et les autorisations. 

• JAMon (Java Application Monitor), pour surveiller les performances. 

• Log4j pour les traces applicatives. 

• Rome pour gerer les flux RSS. 

Concernant le stockage des donnees, Tudu Lists est portable d'une base de donnees a une 
autre, grace a F utilisation de JPA. Cependant, pour le developpement, la base de donnees 
HSQLDB est privilegiee. 

Modelisation 

Tudu Lists est modelisee selon une architecture en couches. La figure 1-11 illustre le modele 
de domaine de Tudu Lists, dont les classes sont persistees via JPA. 



Figure 1-11 

Modele de domaine 
de Tudu Lists 



TodoList 



-id 

-name 
-rssAI lowed 
-last Update 



Todo 



-id 

-creationDate 

-description 

-priorite 

-completed 

-dueDate 

-notes 

-hasNotes 



User 



-login 
-password 
-first Name 
-last Name 
-email 

-creationDate 
-lastAccessDate 
-enabled 
-dateFormat 



Property 



-key 
-value 



Role 



-role 
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Remarquons que la classe Property sert a stacker les parametres internes de Tudu Lists, 
notamment l'adresse du serveur SMTP necessaire a Fenvoi d'e-mail. Par ailleurs, la classe 
Rol e ne contient que deux lignes en base de donnees, chacune representant les deux roles 
geres par Tudu Lists : administrateur et utilisateur. 

La figure 1-12 illustre les services fonctionnels principaux de Tudu Lists (ceux qui permettent 
de gerer les Todos et les listes de Todos), avec la couche de persistance, laissant apparaitre 
clairement la decomposition en couches. 



Figure 1-12 

Services fonctionnels 
de Tudu Lists 



ft 



TodoList 



-id 

-name 
-rssAI lowed 
-last Update 



Todo 



-id 

-creation Date 

-description 

-priorite 

-completed 

-dueDate 

-notes 

-hasNotes 
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« interface» 
TodosManager 



hcreateTodo() 
hdeleteTodo() 
hfindTodo() 
hupdateTodo() 
hCompleteTodoO 
reopenTodo() 
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« singleton» 
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« interface» 
TodoList DAO 



+ getTodoList() 
+ saveTodoList() 
+ updateTodoList() 
+ removeTodoList() 

A 

« singleton» 
TodoList DAOJpa 
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« interface» 
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+ removeTodo() 
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« singleton» 
TodoDAOJpa 
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Conclusion 

Nous avons vu la place occupee par Spring au sein de la plate-forme Java. Avec d'autres 
projets Open Source, Spring contribue a combler certaines limites de Java EE tout en apportant 
des solutions innovantes. 

Cette contribution, d'abord materialisee dans le modele de programmation, prend desormais 
la forme d'une plate-forme d'execution ambitieuse, fondee sur un modele de composants 
dynamiques. 

Nous avons aborde un ensemble de concepts qu'il est essentiel de connaitre pour utiliser 
Spring au mieux et beneficier pleinement de sa puissance. Ces concepts sont la programmation 
par interface, F injection de dependances, la notion de conteneur leger et la decomposition en 
couches pour les applications d'entreprise. 

L' etude de cas Tudu Lists est batie autour de ces concepts essentiels. 



Partie I 



Les fondations de Spring 



Spring est bati sur deux piliers : son conteneur leger et son framework de POA. Pour utili- 
ser Spring de maniere efficace dans nos developpements et beneficier pleinement de sa 
puissance, il est fondamental de bien comprendre les concepts lies a ces deux piliers et de 
modeliser nos applications en consequence. 

Les chapitres 2 et 3 couvrent le conteneur leger de Spring. Nous verrons dans un premier 
temps ses fonctionnalites elementaires puis des concepts et techniques plus avances. 

Le chapitre 4 aborde les principes de la POA a travers une fonctionnalite transverse de 
l'application Tudu Lists. Lobjectif de ce chapitre n'est pas d'etre exhaustif sur le sujet, 
mais de presenter les notions essentielles de la POA. 

Le chapitre 5 traite des differentes facons de faire de la POA dans Spring. 

Le chapitre 6 est consacre aux tests unitaires, une pratique essentielle du developpement 
logiciel. Nous verrons comment tester les differentes couches d'une application et 
comment Spring facilite les tests unitaires grace aux bonnes pratiques qu'il preconise et a 
son framework dedie aux tests. 



2 

Le conteneur leger de Spring 



Le chapitre precedent a introduit la notion de conteneur leger et montre qu'elle ameliorait de 
maniere significative la qualite d'une application. C'est a partir de ces bases conceptuelles que 
nous abordons ici le conteneur leger de Spring. 

Spring propose une multitude de facons d'utiliser son conteneur leger, ce qui est souvent 
deroutant pour le developpeur decouvrant cet outil. Afin de permettre au lecteur d'utiliser effi- 
cacement le framework, nous nous concentrons dans le present chapitre sur les fonctionnalites 
utilisees par la grande majorite des projets. 

Nous commencons par un exemple introductif permettant de comprendre la syntaxe et le 
fonctionnement de Spring. Nous enchainons ensuite avec les differentes techniques dont nous 
disposons pour definir nos objets, ainsi que leurs dependances au sein du conteneur leger. 
II s'agit la du cceur de 1' implementation par Spring du principe d'injection de dependances. 
Nous voyons ensuite comment definir des Beans a partir d' annotations, car Spring n'est pas 
forcement synonyme de configuration XML. 

Nous continuons par des considerations sur le fonctionnement interne du conteneur, car il est 
parfois necessaire qu'une application s'integre etroitement avec celui-ci. Nous finissons par le 
support pour Finternationalisation que propose Spring. 

Premiers pas avec Spring 

Le conteneur leger de Spring peut etre vu comme une simple fabrique d'objets Java. Son fonc- 
tionnement de base consiste a definir des objets dans un fichier XML. Ce fichier est ensuite 
charge par Spring, qui gere alors Finstanciation des objets. 
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On appelle generalement « contexte » l'objet Spring contenant les objets decrits dans le 
fichier XML. Le contexte propose un ensemble de methodes pour recuperer les objets qu'il 
contient. Nous allons detailler l'ensemble de ces etapes afin d'introduire progressivement les 
principes du conteneur leger de Spring et 1' API correspondante. 

Instantiation du conteneur leger de Spring 

Commencons par definir un utilisateur de Tudu Lists dans le conteneur leger de Spring. Voici 
le fichier de configuration XML correspondant : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. spri ngfrarnework.org/schema/beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xsi : schema Location=" http://www.spr ingframework.org/schema/beans 

http: //www. spri ngf ramework.org/schema/beans/spring-beans .xsd"><— © 

<bean id="user" class="tudu. domain. model .User"><—@ 

<property name="f i rstName" value="Frederic" /><— Q 

<property name="l astName" val ue="Chopi n" /><— Q 
</bean> 

</beans> 

Le fichier XML commence par la declaration du schema utilise (©)> qui definit les bali- 
ses utilisables. Nous verrons par la suite les differents schemas XML disponibles dans 
Spring. Nous utilisons ici le schema beans, qui permet de definir des objets Java ainsi que 
leurs proprietes, avec des definitions explicites (comme le nom complet de la classe a 
instancier). 

Nous definissons au repere Q notre Bean (balise bean) en lui donnant un identifiant (attribut 
id) au sein du contexte Spring et en precisant sa classe (attribut class). Nous assignons 
ensuite deux proprietes (Q et Q) avec la balise property et les attributs name (pour le nom de 
la propriete) et val ue (pour la valeur correspondante). 



Qu'est-ce qu'un Bean ? 

Dans le monde Java, un Bean est un objet, c'est-a-dire une instance d'une classe Java. Ce terme de Bean 
fait reference a la specification JavaBeans de Sun, qui definit un ensemble de regies que doivent respecter 
des objets (existence d'accesseurs et de modificateurs pour les proprietes et support d'un mecanisme 
d'observation). Le mot Bean signifie notamment « grain de cafe » en anglais. De meme, Java renvoie non 
seulement a une Tie de I'archipel indonesien (grand producteur de cafe), mais a un mot d'argot americain 
signifiant cafe. 

On utilise souvent les termes Bean Java et POJO de fagon interchangeable. Un POJO (Plain Old Java 
Object) est en fait un simple objet Java, ne faisant reference a aucune classe ou interface technique. Ce 
terme est apparu pour s'opposer aux premieres versions des EJB, dont la composante technique detei- 
gnait invariablement sur les classes du domaine metier. Nous employons dans ce livre le terme Bean prin- 
cipalement pour designer des objets geres par le conteneur leger de Spring. 
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Le fichier de configuration XML peut ensuite etre charge en faisant appel aux differentes classes 
disponibles dans Spring, comme dans l'exemple suivant : 

import org. springf ramework. context . Appl icationContext ; 
import org. springf ramework. context .support. 
Fi 1 eSystemXml Appl i cat i onCon text ; 

import tudu. domain. model .User; 

public class StartSpring { 

public static void main(String[] args) { 

Appl icationContext context = new 

Fi 1 eSystemXml Appl i cati onContext ( 
"appl i cati onContext. xml " 

User user = (User) context. getBean( "user" ) ;<— © 

System. out. println( 
"Utilisateur : "+user.getFirstName()+" "+user.getLastName( )<— © 
); 

1 

} 

Nous declarons une variable context de type Appl icationContext et utilisons l'implemen- 
tation Fil eSystemXml Appl icationContext en lui passant le nom de notre fichier (©). Cette 
implementation localise le fichier sur le systeme de fichiers (et pas dans le classpath). 

Nous pouvons recuperer notre utilisateur de Tudu Lists a partir du contexte, en utilisant la 
methode getBean, avec Fidentifiant en parametre (©). Un transtypage est necessaire, car la 
methode getBean ne connait pas par avance la classe de l'objet. Enfin, nous affichons le fruit 
de notre labeur dans la console (©). 

L execution de ce programme donne la sortie suivante : 



Utilisateur : Frederic Chopin 



Un Appl icationContext peut aussi etre charge avec la classe CI assPathXml Appl ication- 
Context, qui recupere le fichier de definition a partir du classpath. 

Spring permet aussi la definition d'un contexte a partir de plusieurs fichiers. Notre exemple ne 
definit qu'un seul Bean, mais une application d'envergure peut necessiter des dizaines, voire 
des centaines de Beans. On decoupe alors generalement le contexte en plusieurs fichiers. 
Cela facilite leur definition, mais aussi leur reutilisabilite. 

Cet exemple tres simple a introduit les principes de base du conteneur leger de Spring. Nous 
allons maintenant expliciter les differents mecanismes mis en jeu dans notre exemple. 
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Le contexte d 'application de Spring 

Le contexte d' application de Spring correspond a l'interface Appl icationContext. II s'agit du 
point d'entree pour une application qui souhaite utiliser des Beans geres par Spring. Le 
contexte d' application, a travers une interface relativement simple, dissimule des mecanismes 
complexes pour la gestion des Beans. 

Voici quelques methodes de l'interface Appl icationContext : 

Object getBean(String name) throws BeansException; 

Object getBean(String name, Class requi redType) 

throws BeansException; 

boolean containsBean(String name); 

boolean isSingleton(String name) 

throws NoSuchBeanDef ini ti on Except ion ; 

Class getType(String name) throws NoSuchBeanDefinitionException; 
String[] getAliases(String name) 
throws NoSuchBeanDef ini t ion Except i on ; 

La methode contai nsBean verifie, pour un nom donne, qu'un objet correspondant est bien gere 
dans le conteneur leger. 

Les methodes getBean permettent de recuperer l'instance d'un objet a partir de son nom. 
Lune d'elles prend un parametre supplementaire, requi redType, afin de contraindre le type 
d'objet renvoye par getBean pour plus de securite. Si le nom foumi ne correspond pas a un 
objet dont le type est celui attendu, une exception est generee. Par ailleurs, la methode getType 
permet de connaitre le type d'un objet a partir de son nom. 

Un Bean renvoye par la fabrique peut etre un singleton ou non. Nous parlons dans ce dernier 
cas de prototype dans la terminologie Spring. La methode isSingleton permet de savoir, a 
partir du nom d'un objet, s'il s'agit ou non d'un singleton. 

Tout objet dans Spring peut avoir des noms multiples, ou alias. La methode getAl i as fournit 
l'ensemble des alias associes a un objet dont nous connaissons le nom. 

Ces methodes sont en fait issues de l'interface Bean Factory de Spring, dont herite 
Appl i cati onContext. C'est la Bean Factory qui correspond veritablement a la notion de fabrique de 
Beans. 

Le contexte d'application de Spring s'appuie sur une BeanFactory pour la creation des objets, 
mais ajoute les fonctionnalites suivantes : 

• support des messages et de leur internationalisation ; 

• support avance du chargement de fichiers (appeles ressources), que ce soit dans le systeme 
de fichiers ou dans le classpath de 1' application ; 

• support de la publication d'evenements permettant a des objets de l'application de reagir en 
fonction d'eux ; 

• possibilite de definir une hierarchie de contextes, une fonctionnalite tres utile pour isoler les 
differentes couches de l'application (les Beans de la couche presentation ne sont pas visibles 
de la couche service, par exemple). 
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Ces fonctionnalites additionnelles seront presentees plus en detail par la suite, car elles ne 
concernent pas a proprement parler le conteneur leger. 

Les applications d'entreprise utilisant pratiquement systematiquement un contexte 
d' application, nous couvrons done en priori te cette notion. Cependant, il est possible de 
manipuler directement une Bean Factory, mais Ton ne beneficie pas alors des services cites 
precedemment. 

Le contexte d' application offrant des services de gestion des Beans tres puissants, il devient 
pour une application un element essentiel, susceptible de gerer F ensemble de ses composants 
(services metier et technique, DAO, etc.). 



Etapes de construction d'un Bean 

Un Bean gere par le contexte d'application de Spring suit un chemin complexe, depuis sa definition XML 
jusqu'a sa mise a disposition pour une application. Spring commence par analyser les metadonnees de 
definition des Beans (generalement sous forme XML) pour construire un registre de definitions de Beans. 
Linterface correspondante est BeanDef i ni ti on ; elle contient toutes les informations permettant de creer 
un Bean (identifiant, classe, valeurs des differentes proprietes, etc.). Le contexte d'application delegue la 
creation des Beans a une BeanFactory, qui se fonde sur les definitions. Le contexte d'application gere 
aussi un ensemble de services pour les Beans (publication de messages, gestion de ressources, etc.). La 
notion de definition de Bean est importante, car elle encapsule le chargement des metadonnees d'un 
Bean. II existe done differents moyens de definition de ces metadonnees, la forme XML n'etant que la plus 
connue. 



En resume 

Nous venons de voir un exemple simple de chargement de contexte Spring. Nous avons defini 
un simple objet dans un fichier XML puis fait appel a F API Spring pour charger et recuperer 
cet objet. II y a evidemment peu d'interet a utiliser le conteneur leger de Spring pour ce genre 
de manipulation, mais cela nous a permis d'introduire des concepts essentiels. 

Nous avons directement utilise la notion d'Appl icationContext, le type de conteneur leger de 
Spring le plus puissant. II existe aussi la BeanFactory, mais les applications d'entreprise utilisent 
systematiquement un Appl icationContext, car il propose des fonctionnalites plus puissantes 
pour la gestion des Beans. 

Le conteneur leger de Spring prend toute son envergure pour la construction d' ensembles 
complexes de Beans, car il permet de gerer non seulement F initialisation des Beans, mais 
aussi leurs dependances et des mecanismes tels que Fajout transparent de comportement 
(decoration). 



Definition d'un Bean 

Nous avons aborde la definition d'un Bean. Nous allons voir maintenant chacun des aspects 
de cette definition : principe de configuration XML, nommage, definition des proprietes (de 
types primitifs, mais aussi complexes, e'est-a-dire avec injection de dependances) et la notion 
de portee. 
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Les schemas XML 

La version 2 de Spring a introduit les schemas XML, qui dictent les balises utilisables dans un 
fichier de configuration de Spring. Spring 1 utilisait une DTD pour imposer la syntaxe des 
fichiers XML. 

Pour resumer, cette DTD se limitait a deux balises : bean et property, pour definir respective - 
ment un Bean et ses proprietes. Malgre cette relative simplicite, Spring etait deja un conteneur 
performant, mais sa configuration pouvait s'averer fastidieuse, notamment quand les classes 
des Beans etaient tres longues. La syntaxe generique permettait de repondre a tous les besoins, 
mais pas forcement de la facon la mieux adaptee. 

Les schemas XML ont permis de donner plus de sens aux differentes balises, parce que leur 
nom est explicite et que leur utilisation masque les mecanismes complexes d'instanciation de 
Beans. 

Les schemas XML apportent en outre une modularite a Spring : on utilise seulement ceux 
dont on a besoin dans un fichier. Enfin, ils apportent une tres bonne extensibilite. II est ainsi 
possible de definir son propre schema, qui, lorsqu'il sera utilise dans un fichier de contexte 
Spring, s'interfacera avec le conteneur leger et creera des Beans. 

Spring peut done etre utilise potentiellement pour tout type de projet necessitant une configu- 
ration declarative et Finjection de dependances, et pas uniquement des applications. Bref, les 
schemas XML apportent simplicite et expressivite a la configuration de Spring. 

Lexemple suivant (issu de la documentation de reference de Spring) montre, pour la defini- 
tion d'une liste d'e-mails la difference entre la syntaxe fondee sur la DTD Spring 1 et les schemas 
XML de Spring 2 : 

<!-- Spring 1 et DTD --> 
<bean id="emails" 
cl a ss-" org. springframework. beans. factory. config. List Factory Bean "> 
<property name="sourceList"> 
<list> 

<val ue>pechorin@hero.org</val ue> 
<val ue>raskol ni kov@sl urns .org</val ue> 
<val ue>stavrogin@gov.org</val ue> 
<val ue>porfi ry@gov.org</val ue> 
</list> 
</property> 
</bean> 

<!--schema XML --> 
<util:list id="emails"> 

<val ue>pechorin@hero.org</val ue> 

<val ue>raskol ni kov@sl urns .org</val ue> 

<val ue>stavrogin@gov.org</val ue> 

<val ue>porf i ry@gov .org</val ue> 
</util :list> 
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Le tableau 2-1 recapitule les schemas XML disponibles dans Spring 2.5. 



Tableau 2-1. Schemas XML de Spring 2.5 



Nom 


Description 


beans 


Definition des Beans et de leurs dependances 


aop 


Gestion de la programmation orientee aspect 


context 


Activation des annotations et positionnement de post-processeurs 


util 


Declaration de constantes et de structures de donnees 


jee 


Fonctions pour s'interfacer avec JNDI et les EJB 


jms 


Configuration de Beans JMS 


lang 


Declaration de Beans definis avec des langages de script, tels que JRuby ou Groovy 


P 


Definition des proprietes de Beans 


tx 


Declarations des transactions sur des Beans 



Voici un fichier declarant l'ensemble des schemas XML disponibles : 
<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spri ngframework.org/schema /beans" 
xml ns :xsi="http: //www. w3.org/2001/XMLSchema -instance" 
xml ns : aop="http: //www. spri ngframework.org/schema/aop" 
xml ns : context="http : //www. spri ngf ramework. org/schema/context" 
xml ns : jee="http: //www. spri ngframework.org/schema/jee" 
xml ns : jms="http: //www. spri ngframework.org/schema/jms" 
xml ns : 1 ang="http : //www. spri ngf ramework. org/schema /I ang" 
xml ns:p=" http://www.springframework.Org/schema/p" 
xml ns :tx-"http: //www. springframework.org/schema/tx" 
xml ns : uti l="http : //www. spri ngf ramework.org/schema/uti 1 " 
xsi :s enema Locati on="http: //www. springframework.org/schema/beans 

http://www.springframework.org/schema/beans/spring-beans.xsd 

http: //www. springframework.org/schema/aop 

http://www.springframework.org/schema/aop/spring-aop.xsd 
http: //www. springframework.org/schema/context 

http://www.springframework.org/schema/context/spring-context.xsd 
http: //www. springframework.org/schema/jee 

http://www.springframework.org/schema/jee/spring-jee.xsd 
http: //www. springframework.org/schema/jms 

http: //www. springframework.org/schema/jms/spring- jms .xsd 
http: //www. spri ngf ramework. org/ schema /l ang 

http://www.springframework.org/schema/lang/spring-l ang. xsd 
http: //www. springframework.org/schema/tx 

http: //www. springframework.org/schema/tx/spri ng-tx.xsd 
http: //www. springframework.org/schema/uti 1 

http: //www. springframework.org/schema/uti 1 /spring -uti 1 .xsd"> 



</beans> 
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Dans les chapitres consacres au conteneur leger, nous utiliserons principalement les schemas 
beans, util et context. 



Nommage des Beans 

Un Bean doit generalement avoir un identifiant dans le contexte Spring, afin qu'il puisse etre 
reference par la suite. L'identifiant est fixe avec Fattribut id de la balise bean : 

<bean id="user" class="tudu. domain. model .User"> 

L'identifiant doit bien sur etre unique. II s'agit d'un identifiant au sens XML du terme. Cela 
presente des avantages, comme le fait qu'un editeur approprie vous signalera les doublons, 
mais aussi des inconvenients, car la syntaxe d'un identifiant XML est imposee (il ne peut pas 
commencer par un chiffre, par exemple). 

Pour remedier a ce probleme, Spring propose Fattribut name, qui permet de definir des alias : 

<bean id="user" cl ass="tudu. domain. model .User" 
name="tudul_istsUser\piani st"> 

Les methodes d'injection 

L'essentiel de la puissance de Spring reside dans l'injection de dependances, c'est-a-dire dans 
F initialisation des proprietes d'un Bean, qu'elles soient simples (entier, reel, chaine de carac- 
teres, etc.) ou qu'elles fassent reference a d'autres Beans geres par le conteneur. Nous parlons 
dans ce dernier cas de collaborateurs. 

Pour initialiser les proprietes d'un Bean, Spring propose deux methodes d'injection : soit en 
utilisant les modificateurs du Bean, s'il en a, soit en utilisant l'un de ses constructeurs. 

L'injection par modificateur 

L'injection par modificateur se parametre au sein d'une definition de Bean en utilisant le tag 
property. Ce tag possede un parametre name specifiant le nom de la propriete a initialiser. 

Rappelons qu'un modificateur ne correspond pas forcement a un attribut de l'objet a initialiser 
et qu'il peut s'agir d'un traitement d'initialisation plus complexe. 

Definition du modificateur 

La presence d'un modificateur est essentielle a l'injection par modificateur. Cela peut paraitre evident, 
mais oublier de definir le modificateur pour une propriete est une erreur frequente qui fait echouer le 
demarrage du contexte Spring. 



Le tag property s'utilise en combinaison avec le tag value, qui sert a specifier la valeur a 
affecter a la propriete lorsqu'il s'agit d'une propriete canonique, ou avec le tag ref, s'il s'agit 
d'un collaborateur. 
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Nous avons deja vu la definition par modificateur dans notre premier exemple : 

<bean id="user" cl ass="tudu . domain. model .User"> 

<property name="f i rstName" value="Frederic" /> 

<property name="l astName" val ue="Chopin" /> 
</bean> 

II est possible d'utiliser une balise val ue imbriquee, mais la syntaxe devient plus verbeuse : 

<bean id="user" class-"tudu. domain. model .User"> 

<property name="fi rstName"Xval ue>Frederic</val ueX/property> 
<property name-"l astName"Xval ue>Chopin</val ue></property> 

</bean> 

Linjection par constructeur 

L'injection par constructeur se parametre au sein d'une definition de Bean en specifiant les 
parametres du constructeur par le biais du tag constructor-arg. 

Supposons que nous ayons une classe UnBean codee de la maniere suivante : 
public class UnBean { 

private String chaine; 
private Integer entier; 

public UnBean(String chaine, Integer entier) { 
super( ) ; 

this. chaine = chaine; 
this. entier = entier; 

} 

} 

La configuration de ce Bean s'effectue ainsi : 

<bean id="monBean" cl ass="UnBean"> 

<constructor-arg value="chaine " /> 

<constructor-arg value="10" /> 
</bean> 

II est possible de changer Fordre de definition des parametres du constructeur en utilisant le 
parametre index du tag constructor-arg. L'indexation se fait a partir de 0. 

La configuration suivante est equivalente a la precedente, bien que nous ayons inverse Fordre 
de definition des parametres du constructeur : 

<bean id="monBean" cl ass="UnBean"> 

<constructor-arg value="10" index="l" /> 

<constructor-arg value="chaine" index="0" /> 
</bean> 

Dans certains cas, il peut y avoir ambiguite dans la definition du constructeur, empechant 
Spring de choisir correctement ce dernier. Pour illustrer ce probleme, ajoutons les deux 
constructeurs a la classe UnBean : 
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public UnBean(String chaine) { 
this. chaine = chaine; 

} 

public UnBean( Integer entier) { 
this.entier = entier; 

} 

Si nous ecrivons la definition de Bean suivante, une ambigui'te apparait, puisque les deux 
constracteurs peuvent etre utilises a partir de ce parametrage : 

<bean id="monBean" class=" UnBean"> 

<constructor-arg value="10" /> 
</bean> 

Par defaut, Spring selectionne le premier constructeur supportant cette configuration, en 
Foccurrence celui qui initialise Fattribut chaine. Pour lever Fambiguite, il est possible d'utiliser 
le parametre type du tag constructor-arg : 

<bean id="monBean" class=" UnBean"> 

<constructor-arg value="10" type="java.lang. Integer" /> 
</bean> 

Grace a ce parametre, nous selectionnons le constmcteur qui initialise entier. Pour selectionner 
F autre constructeur explicitement, nous pouvons ecrire : 

<bean id="monBean" cl ass="UnBean"> 

<constructor-arg val ue="chaine" type="java.lang. String" /> 
</bean> 



Injection par modificateur ou par constructeur ? 

Dans le cadre de Spring, I'injection par modificateur est generalement preferee. Linjection par constructeur 
peut devenir malcommode si les dependances sont nombreuses et si certaines sont optionnelles. Linjec- 
tion par modificateur laisse quant a elle toute la souplesse necessaire pour les dependances optionnelles. 
Elle permet aussi un changement a chaud des dependances, par exemple dans le cas d'une gestion de 
I'objet via MX. L'injection par constructeur permet de definir un contrat fort : un objet doit etre initialise 
avec toutes ses dependances ou ne pas exister. Elle est generalement preferee (a juste titre) par les puristes 
de la programmation orientee objet. II n'y a done pas de reponse unique a la question, meme si l'injection 
par modificateur est la plus utilisee avec Spring. 

Injection des proprietes 

Nous allons voir dans cette section comment Spring gere l'injection de valeurs simples 
(notamment les types primitifs) et les structures de donnees. 

Injection de valeurs simples 

Spring supporte l'injection de valeurs simples en convertissant les chaines de caracteres fournies 
a Fattribut val ue dans le type de la propriete a initialiser. 
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Outre les chaines de caracteres et les nombres, les types de proprietes supportes par Spring 
sont les suivants : 

• booleens 

• type char et java.lang. Character ; 

• type java.util .Properties ; 

• type java . uti 1 . Local e ; 

• type java. net. URL ; 

• type java. io. File ; 

• type java.lang. Class ; 

• tableaux de bytes (chaine de caracteres transformee via la methode getBytes de String) ; 

• tableaux de chaines de caracteres (chaines separees par une virgule, selon le format CSV). 

Afin d'illustrer Futilisation de ces differentes valeurs, nous modifions notre classe UnBean en 
consequence : 

public class UnBean { 
private String chaine; 
private int entier; 
private float reel ; 
private boolean booleen; 
private char caractere; 
private java.util .Properties proprietes; 
private java . uti 1 . Local e localisation; 
private java. net. URL url ; 
private java. io. File fichier; 
private java.lang. Class classe; 
private byte[] tab2bytes; 
private String[] tab2chaines; 

// definition des accesseurs et modificateurs de chaque attribut 
(...) 
} 

Si nous utilisons l'injection par modificateur, plus explicite, la definition du Bean est la 
suivante : 

<bean id="monBean" cl ass="UnBean"> 
<property name="chaine" val ue="val eur" /> 
<property name="entier" value="10" /> 
<property name-"reel" val ue="10 . 5" /> 
<property name="bool een" value="true" /> 
<property name="caractere" value="a" /> 
<property name="proprietes"> 
<val ue> 

log4j .rootLogger=DEBUG, CONSOLE 
log4j . logger. tudu=WARN 
</val ue> 
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</property> 

<property name="localisation" val ue="f r_FR" /> 
<property name="url" val ue="http: //tudu. sf.net" /> 
<property name="fichier" value="file:c:\\temp\\test.txt" /> 
<property name="cl asse" value-"java.lang. String" /> 
<property name="tab2bytes" val ue="val eur" /> 
<property name="tab2chaines" value="valeurl,valeur2" /> 
</bean> 

Spring supporte les types les plus utilises, mais, pour des besoins specifiques, il peut etre 
necessaire de supporter de nouveaux types. Nous etudions cette possibilite au chapitre 3. 

Injection de la valeur null 

Dans certaines situations, il est necessaire d'initialiser explicitement une propriete a null. 
Pour cela, Spring propose le tag nul 1 . 

La configuration suivante passe une valeur nulle au premier parametre du constructeur de 
UnBean : 

<bean id="monBean" cl ass="UnBean"> 
Constructor- a rgXnul 1 /></ constructor- a rg> 

<constructor-arg value="10" /> 
</bean> 

Injection de structures de donnees 

Outre les valeurs simples, Spring supporte Finjection de structures de donnees. Ces demieres 
peuvent stocker soit des ensembles de valeurs simples (balise val ue), soit des objets geres par 
le conteneur (balise ref), dont nous verrons la definition un peu plus loin. 

Les structures de donnees peuvent etre definies afin d'etre injectees dans un autre Bean. Elles 
n'ont alors pas d'identifiant, et Ton peut les qualifier de Beans anonymes. Pour ce genre de 
definition, le schema beans propose des balises utilisables seulement au sein d'une balise 
property. 

Si les structures de donnees doivent avoir une identite a part entiere, il est possible de les 
declarer avec des balises du schema util. On peut alors leur attribuer un identifiant et les 
reutiliser ailleurs dans le conteneur. 

Les structures de donnees supportees sont java.util .Map, java.util .Set et java.util .List. 
Outre ces trois types, Spring fournit des balises specifiques pour initialiser les proprietes du 
type java . uti 1 . Properties. Ces balises sont plus lisibles que la configuration que nous avons 
utilisee precedemment (lors de Finjection de valeurs simples). 

Notons que, contrairement aux structures de donnees precedentes, la classe Properties 
n'accepte que les chaines de caracteres, puisqu'il s'agit du seul type qu'elle est capable de 
manipuler. 
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Le type java.util.Map 

L'interface java . uti 1 .Map represente un objet qui fait correspondre des cles a des valeurs. Une 
Map ne peut contenir de cles dupliquees (elles sont uniques), et une cle ne peut correspondre 
qu'a une seule valeur. 

Voici comment assigner une Map a la propriete d'un Bean (balises map et entry) : 
<property name="map"> 



<map> 










<entry 


key="c 


el" 


val ue="va 


eurl'7> 


<entry 


key="c 


e2" 


val ue="va 


eur2'7> 


</map> 











</property> 

Voici comment definir explicitement une Map en tant que Bean : 

<util:map id="mapBean"> 

<entry key-"clel" value="valeurl"/> 

<entry key-"cle2" val ue="val eur2"/> 
</uti 1 :map> 

Spring gere alors la classe d' implementation. Nous pouvons preciser celle-ci avec l'attribut 
map-class : 

<util :map id="mapBean" map-cl ass=" java . uti 1 .HashMap" > 

Le type java.util.Set 

L'interface java . uti 1 . Set est une collection d'elements qui ne contient aucun dupliqua et au 
maximum une fois la valeur nul 1 . Ce type correspond a la notion mathematique d'ensemble. 

Voici comment assigner un Set a la propriete d'un Bean (balises set et val ue) : 

<property name="set"> 
<set> 

<val ue>val eurl</val ue> 
<val ue>val eur2</val ue> 
</set> 
</property> 

Voici comment definir explicitement un Set en tant que Bean : 

<util:set id="setBean"> 

<val ue>val eurK/val ue> 

<val ue>val eur2</val ue> 
</ut1l :set> 

Spring masque alors la classe d' implementation. II est possible de preciser celle-ci avec 
l'attribut set-cl ass : 

<util:set id="setBean" set-cl ass=" java . uti 1 . HashSet" > 

<val ue>val eurK/val ue> 

<val ue>val eur2</val ue> 
</util :set> 
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Le type java.util.List 

L' interface j ava . uti 1 . Li st est une collection ordonnee d'elements. A ce titre, ce type permet 
un controle precis de la facon dont chaque element est insere dans la liste. L'ordre de definition 
des valeurs est done pris en compte. 

Voici comment assigner une Li st a la propriete d'un Bean (balises 1 i st et val ue) : 

<property name="l i st"> 
<list> 
<val ue>val eurl</val ue> 
<val ue>val eur2</val ue> 
</list> 
</property> 

Voici comment definir explicitement une List en tant que Bean : 

<util:list id="l istBean"> 

<val ue>val eurl</val ue> 

<val ue>valeur2</val ue> 
</ut1l :list> 

Spring gere alors la classe d' implementation. II est possible de preciser celle-ci avec Fattribut 
1 i st-cl ass : 

<util : 1 ist id="l istBean" 1 i st-cl ass-" java . uti 1 .ArrayList"> 

Le type java.util. Properties 

Comme nous Favons vu precedemment, il est possible d'initialiser une propriete de type 
java . uti 1 . Properti es directement a partir d'une chaine de caracteres. Spring propose cependant 
une autre methode, plus lisible, a l'aide de balises. 

Voici comment assigner des Properties a la propriete d'un Bean : 

<property name="props"> 
<props> 

<prop key="cl el">val eurl</prop> 
<prop key="cl e2">val eur2</prop> 
</props> 
</property> 

Voici comment definir explicitement des Properties en tant que Bean : 

<util :properties id="propsBean"> 

<prop key="cl el">valeurl</prop> 

<prop key="cl e2">val eur2</prop> 
</util :properties> 

Injection des collaborateurs 

Nous venons de voir comment initialiser les valeurs simples ainsi que les structures de donnees au 
sein d'un objet gere par le conteneur leger. Spring supporte en standard les types les plus 
frequemment rencontres pour les attributs d'une classe. II fournit en outre les transformateurs 
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necessaires pour convertir la configuration effectuee sous forme de chaines de caracteres en 
une valeur ayant le type convenable. 

Nous allons nous interesser a present a l'injection des proprietes particulieres que sont les 
collaborateurs. 

Comme nous Favons deja indique, la terminologie de Spring designe par le terme collaborateur 
une propriete d'un Bean etant elle-meme un Bean gere par le conteneur leger. 

Pour realiser l'injection des collaborateurs, Spring propose deux methodes, Fune explicite, 
chaque collaborateur etant defini dans le fichier de configuration, F autre automatique, le conte- 
neur leger decidant lui-meme des injections a effectuer {autowiring) par introspection des Beans. 
Une fois l'injection effectuee, il est possible de proceder a une verification des dependances 
afin de s' assurer que les Beans ont ete correctement initialises. 

Injection explicite des collaborateurs 

L'injection explicite des collaborateurs est la maniere la plus sure de gerer les dependances 
entre les Beans geres par le conteneur leger, car toute la mecanique d' injection est sous 
controle du developpeur (contrairement a l'injection automatique, ou Spring prend des decisions). 

Comme indique precedemment, les collaborateurs sont des proprietes. A ce titre, ils se confi- 
gured a l'aide du tag property. Cependant, la balise ou l'attribut val ue sont ici remplaces par 
ref, signifiant reference. 

Dans Tudu Lists, l'injection de collaborateurs est utilisee pour les services metier, qui ont 
besoin d'objets d'acces aux donnees, auxquels ils deleguent les interactions avec la base de 
donnees. Le service tudu. service. impl .UserManagerlmpl a, par exemple, une propriete 
userDAO, qui doit recevoir un Bean implementant l'interface tudu. domain.dao. Use rDAO. 

Voici comment injecter une implementation JPA de ce DAO dans le service : 
<bean id="userDAO" class="tudu. domain. dao. jpa.llserDAOJpa" /><— O 

<bean id="userManager" 

class="tudu. service. impl .UserManagerlmpl "><— Q 
<property name="userDAO" ref="userDAO" /><— Q 
</bean> 

Nous declarons dans un premier temps le DAO (©), puis seulement le service (Q). Le DAO 
est injecte via la balise property, dont nous utilisons l'attribut ref pour faire reference a notre 
DAO (©). 

Pour injecter un Bean, il n'est pas necessaire qu'il soit defini separement aupres du conteneur 
leger. II est possible de le declarer pour une injection unique a l'interieur de la balise property. 
Voici l'injection du DAO dans notre service metier, sans que le Bean DAO soit declare expli- 
citement dans le conteneur leger : 

<bean id="userManager" class="tudu. service. impl .UserManagerlmpl "> 

<property name="userDAO"> 

<bean class="tudu. domain. dao. jpa.UserDAOJpa" /> 

</property> 
</bean> 



Les fondations de Spring 

Partie I 



Une balise bean est directement utilisee au sein de la balise property. II serait aussi possible 
d'utiliser des balises property pour configurer des proprietes du DAO. 

II n'est pas utile de nommer un Bean interne, puisqu'il n'est pas visible en dehors de la defini- 
tion dans laquelle il s'inscrit. L'interet d'un Bean interne est son cote invisible : il ne peut etre 
recupere a partir du contexte. On peut le voir comme un composant anonyme d'un contexte 
d' application. En revanche, il ne peut etre reutilise pour etre injecte dans plusieurs Beans. 

Injection automatique des collaborateurs 

Nous avons vu que F injection explicite impliquait l'ecriture de plusieurs lignes de configuration. 
Sur des projets de grande faille, les configurations peuvent rapidement devenir imposantes. 

Pour reduire de maniere drastique le nombre de lignes de configuration, Spring propose un 
mecanisme d' injection automatique, appele autowiring. Ce mecanisme utilise des algorithmes 
de decision pour savoir quelles injections realiser. 

Le tableau 2-2 recapitule les differents modes d' autowiring proposes par Spring. 



Tableau 2-2. Modes d'autowiring de Spring 



Mode 


Description 


no 


Aucun autowiring n'est effectue, et les dependances sont assignees explicitement. II s'agit du 
mode par defaut. 


byName 


Spring recherche un Bean ayant le meme nom que la propriete pour realiser I'injection. 


byType 


Spring recherche un Bean ayant le meme type que la propriete pour realiser I'injection. Si plusieurs 
Beans peuvent convenir, une exception est lancee. Si aucun Bean ne convient, la propriete est ini- 
tialise© & null . 


constructor 


Similaire a byType, mais fonde sur les types des parametres du ou des constructeurs 


autodetect 


Choisit d'abord I'injection par constructeur. Si un constructeur par defaut est trouve (c'est-a-dire 
un constructeur sans argument), passe a I'injection automatique par type. 



L' autowiring est un mecanisme puissant permettant de fortement alleger les fichiers de confi- 
guration de Spring. II ne doit cependant etre utilise que pour des applications dans lesquelles 
les dependances restent relativement simples. 

Tudu Lists utilise de F autowiring, car les dependances decoulent d'une architecture en couches 
et sont done claires. L autowiring est a proscrire pour les applications ou les liaisons entre 
composants doivent apparaitre explicitement et clairement, surtout si elles sont complexes. 

II existe deux moyens d'activer 1' autowiring dans Spring : soit avec la configuration XML, 
soit avec des annotations. Les modes que nous avons presentes sont utilises dans la configuration 
XML, mais leurs principes sont identiques dans la configuration par annotations. 

Injection automatique en XML 

Pour la configuration XML, l'autowiring peut-etre active Bean par Bean par le biais de l'attri- 
but autowi re de la balise bean, ce qui permet d'utiliser ce mode d'injection de maniere ciblee. 
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Voici, par exemple, comment injecter automatiquement le DAO dans le service metier de 
gestion des utilisateurs de Tudu Lists : 

<bean id="userManager" class="tudu. service. impl .UserManagerlmpl " 
autowi re="byType" /> 

<bean id="userDAO" class="tudu. domain. dao. jpa.UserDAOJpa" /> 

Comme la propriete se nomme userDAO, remarquons que Fautowiring par nom fonctionnerait 
aussi dans le cas suivant : 

<bean id="userManager" class="tudu. service. impl .UserManagerlmpl " 
autowi re="byName" /> 

<bean id="userDAO" class="tudu. domain. dao. jpa.UserDAOJpa" /> 

Par defaut, aucun autowiring n'est effectue dans une configuration XML. II est possible de 
positionner Fattribut default -autowi ring de 1' attribut racine beans arm de definir globalement 
le mode d' autowiring : 

<beans (...) default-autowi re="byType" > 

Injection automatique par annotation 

L autowiring via XML a des limites, puisqu'il agit globalement sur les proprietes d'un objet. 
II est possible de parameter plus finement Fautowiring avec des annotations. 

Les annotations supportees sont @Autowired (issue de Spring) et ©Resource (issue de la JSR 
250 Commons Annotations, qui est normalement utilisee pour injecter des ressources JNDI). 

Ces annotations peuvent etre apposees sur des proprietes, des constructeurs ou des modifica- 
teurs (nous nous contenterons d'exemples sur les proprietes, mais les principes sont identiques 
dans les deux autes cas). Nous allons illuster nos exemples avec @Autowi red, le fonctionnement 
de ©Resource etant pratiquement equivalent. 

Par defaut, la detection des annotations n'est pas activee. II existe deux facons de Factiver. La 
premiere consiste a utiliser la balise annotation-config du schema context, qui active la 
detection d'un ensemble d' annotations dans Spring : 

<?xml version="1.0" encoding-"UTF-8"?> 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 

xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xml ns : context="http:/ /www. springframework.org/schema/context" 

xsi : schema Location="http: //www. springframework.org/schema/beans 

http://www.springframework.org/schema/beans/spring-beans.xsd 

http://www.springframework.org/schema/context 

http://www.springframework.org/schema/context/spring-context.xsd"> 
<context:annotation-config /> 



</beans> 
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La seconde facon d'activer la detection des annotations consiste a declarer dans le contexte un 
Bean specifique, appele BeanPostProcesseur, qui effectuera l'injection automatiquement lors 
du chargement du contexte : 

<bean cl ass="org.springf ramework. beans .factory .annotation. 
Autowi redAnnotationBeanPostProcessor" /> 

Si nous reprenons l'exemple du service utilisateur de Tudu Lists, dans lequel un DAO est 
injecte, en supposant que la detection des annotations est activee, la declaration des deux 
Beans est la suivante : 

<bean id="userManager" cl ass="tudu. service. impl . UserManagerlmpl " /> 

<bean id="userDAO" class="tudu. domain. dao. jpa.UserDAOJpa" /> 

Pour que Fautowiring ait lieu, nous utilisons l'annotation ©Autowi red sur la propriete userDAO 
du service : 

(...) 

import org.springf ramework. beans .factory .annotation. Autowi red; 
(...) 

public class UserManagerlmpl implements UserManager { 
©Autowi red 

private UserDAO userDAO; 
(...) 

} 

Lutilisation de @Autowired n'impose pas l'existence du modificateur de la propriete injectee, 
Spring pouvant effectuer l'injection par introspection. Si cette pratique ne respecte pas rigou- 
reusement le paradigme objet, elle economise du code, ce qui est commode sur des Beans 
ayant de nombreuses proprietes. 

Par defaut, l'annotation ©Autowi red impose une dependance obligatoire. Si Spring n' arrive pas 
a resoudre la dependance, une exception est generee. II est possible de rendre une dependance 
optionnelle avec le parametre requi red : 

©Autowi red ( requi red=f al se ) 
private UserDAO userDAO; 

Avec les annotations, Spring effectue un autowiring par type. Dans le cas ou plusieurs Beans 
correspondent au type d'une dependance, il faut indiquer a Spring comment lever les ambi- 
guites. Cela se fait au moyen de l'annotation ©Qualifier, qui permet d'aiguiller Spring dans 
Fautowiring. 

Prenons l'exemple d'un service metier envoyant des messages d'information aux clients d'un 
systeme informatique. La forme de F envoi varie selon Fabonnement du client : e-mail pour les 
clients avec Fabonnement « standard » et SMS pour les clients avec Fabonnement « gold ». 
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D'un point de vue objet, nous avons une interface MessageSender et deux implementations, 
SmsMessageSender et Emai 1 MessageSender. Notre service metier a une propriete pour chacun 
des types d' envois : 

public class AlerteClientManager { 

private MessageSender senderPourAbonnementGold; 
private MessageSender senderPourAbonnementStandard; 
(...) 

} 

Notons, d'une part, que nous raisonnons par interface (les proprietes sont de type 
MessageSender) et, d'autre part, que les noms des proprietes ont une connotation semantique 
plutot que technique. Nous ne faisons done pas reference aux technologies sous-jacentes 
(SMS et email). 

Le fichier de configuration XML declare le service et les deux implementations de 
MessageSender : 

<bean id="alerteCl ientManager" class="AlerteClientManager" /> 

<bean id="goldMessageSender" cl ass="SmsMessageSender" /> 
<bean id="standardMessageSender" class="EmailMessageSender" /> 

II faut annoter les deux proprietes du service metier, arm d'effectuer automatiquement l'injec- 
tion. Cependant, une annotation @Autowired sur chaque propriete n'est pas suffisante, car 
Spring detecte un conflit (deux Beans implementant MessageSender sont declares dans le 
contexte). L annotation @Qual ifier permet de lever Fambiguite : 

import org. springf ramework. beans. f actory . annotati on. Autowi red; 
import org. springf ramework. beans. f actory. annotation.Qual ifier; 

public class AlerteClientManager { 

@Autowi red 

@Qual ifier( "goldMessageSender") 

private MessageSender senderPourAbonnementGold; 

@Autowi red 

@Qual i f ier( "standardMessageSender" ) 

private MessageSender senderPourAbonnementStandard; 

(...) 



} 
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Le parametre passe a @Qual ifier fait reference au nom du Bean que Spring doit injecter. 
II s'agit du comportement par defaut : le qualificateur d'un Bean prend comme valeur l'iden- 
tifiant dudit Bean si rien n'est precise. 

On peut qualifier explicitement un Bean en imbriquant la balise qual i fier dans la balise bean : 

<bean cl ass="SmsMessageSender"> 

<qualifier val ue="gol dMessageSender" /> 
</bean> 

<bean cl ass="Emai 1 MessageSender"> 

<qualifier val ue="standardMessageSender" /> 
</bean> 

Nous avons supprime l'identifiant des deux Beans, mais ils auraient tres bien pu cohabiter 
avec la balise qualifier. 

La notion de qualificateur permet d'aller beaucoup plus loin que dans notre exemple. Nous 
invitons le lecteur a consulter la documentation de reference de Spring pour voir notamment 
comment creer ses propres annotations de qualification. 

L'injection automatique par annotations permet aussi de recuperer tous les Beans d'un certain 
type. II suffit pour cela de declarer une collection typee dans un Bean : 

public class MessageSenderConfiguration { 

(..J 

©Autowi red 

private Collection<MessageSender> messageSenders ; 
(...) 

} 

Voici un fichier de configuration : 

<bean id="messageSenderConf i guration" 

cl ass="MessageSenderConf i guration" /> 

<bean cl ass="SmsMessageSender" /> 

<bean cl ass="Emai 1 MessageSender" /> 

Le Bean messageSenderConfi guration se verra injecter une collection contenant les deux 
MessageSender declares. La propriete destinee a l'injection peut etre tout type de Collection 
(Set, Li st) ou un tableau d' elements du type attendu. Elle peut aussi etre une Map, dont les cles 
sont des Stri ng et les valeurs du type attendu. Voici la declaration de cette Map pour l'exemple 
precedent : 

@Autowi red 

private Map<String, MessageSender> messageSenders; 

Spring utilisera des lors le nom des Beans pour la cle et les Beans proprement dits pour les 
valeurs correspondantes. 
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L'injection automatique de Beans d'un meme type est particulierement utile quand l'ensem- 
ble de ces Beans n'est pas connu a priori. lis peuvent etre en effet dissemines a travers 
plusieurs fichiers de configuration ou amenes a etre crees via de la detection automatique de 
composant. Ce mecanisme est interessant pour l'extensibilite qu'il offre, car les Beans 
peuvent etre des contributions a un point d' extension de F application, comme les 
messageSenders de notre exemple, qui correspondent aux differents types de messages que 
l'application supporte. 

Quand utiliser l'injection automatique ? 

Comme nous l'avons deja explique, l'injection automatique economise des lignes dans un 
fichier de configuration mais ne contribue pas a la clarte des dependances entre differents 
Beans. Elle est done a utiliser quand l'injection de dependances est simple et repetitive. 

L'utilisation d'annotations pour effectuer l'injection automatique est a limiter aux memes cas 
que l'injection automatique en general. Elle constitue un moyen tres commode de configu- 
ration, malgre son cote intrusif (la classe annotee depend de l'API de 1' annotation). 

Nous verrons au chapitre 6, consacre aux tests unitaires, que cette forme d'injection est parti- 
culierement adaptee. 

II ne faut done pas proscrire systematiquement l'injection automatique, mais plutot essayer 
d'imaginer la solution la mieux adaptee a une application en particulier. Le compromis doit se 
fake en ayant a l'esprit la verbosite de la configuration, la clarte et la complexite des depen- 
dances. 

Injection avec le schema p 

Spring propose un schema XML permettant l'injection des proprietes (simples et collabo- 
rateurs) via des attributs dans la balise bean. 

Pour utiliser ce schema, l'en-tete du fichier XML doit etre le suivant : 
<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spri ngframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns :p="http: //www.springf ramework.org/schema/p" 

xsi : schema Location="http: //www. springframework.org/schema/beans 
http: //www. springf ramework.org/schema/beans/spring-beans .xsd"> 

</beans> 

Les proprietes peuvent ensuite etre assignees en utilisant un attribut avec la syntaxe 
p:${nom-propriete} dans la balise bean. 

Voici notre exemple introductif utilisant le schema p : 

<bean id="user" cl ass="tudu. domain. model .User" 
p : f 1 rstName=" Frederic" p:lastName="Chopin" /> 
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Pour effectuer Finjection d'un collaborateur, il suffit d'ajouter -ref apres le nom de la propriete : 

<bean id="userManager" cl as s="tudu. service. impl . UserManagerlmpl " 
p:userDAO-ref="userDAO" /> 

<bean id="userDAO" class="tudu. domain. dao. jpa .UserDAOJpa" /> 

L'utilisation du schema XML p permet d'obtenir une syntaxe tres concise pour l'injection de 
dependances. SpringlDE supporte bien ce schema et propose une completion de code qui en 
facilite et fiabilise grandement la saisie. 

Selection du mode d'instanciation, ou portee 

Avec Spring, la declaration XML d'un Bean correspond a une definition, et pas directement a une 
instance d'une classe Java. Quand un Bean est recupere avec la methode getBean ou est refe- 
rence pour etre injecte, Spring decide a partir de cette definition comment Fobjet doit etre cree. 
Par defaut, pour une definition donnee, Spring retourne toujours le meme Bean, c'est-a-dire 
que les Beans Spring sont par defaut des singletons. Le modele singleton est la plupart du 
temps celui voulu, d'ou le choix de ce mode d'instanciation par defaut. 
Dans la terminologie des conteneurs legers, on parle de portee pour qualifier le mode 
d'instanciation. 

Les portees proposees par Spring sont recapitulees au tableau 2-3. 



Tableau 2-3. Portees proposees par Spring 



Portee 


Description 


singleton 


Un seul Bean est cree pour la definition. 


prototype 


Une nouvelle instance est creee chaque fois que le Bean est reference. 


request 


Une instance est creee pour une requete HTTP, c'est-a-dire que chaque requete HTTP dispose de sa propre ins- 
tance de Bean, pour toute sa duree de vie. Portee valable seulement dans le contexte d'une application Web. 


session 


Une instance est creee pour une session HTTP, c'est-a-dire que la session HTTP dispose de sa propre ins- 
tance de Bean, pour toute sa duree de vie. Portee valable seulement dans le contexte d'une application Web. 


globalSession 


Une instance est creee pour une session HTTP globale, c'est-a-dire que la session HTTP globale dispose de 
sa propre instance de Bean, pour toute sa duree de vie. Portee valable seulement dans un contexte de portlet. 



La portee d'un Bean se regie avec l'attribut scope de la balise bean : 

<bean id="user" class="tudu. domain. model .User" scope="prototype" /> 



Portees singleton et prototype 

Les portees les plus frequemment utilisees sont singleton et prototype. 

Dans le cas d'une application d'entreprise, la portee singleton est adaptee pour les objets 
pouvant etre accedes de facon concurrente (une application d'entreprise est la plupart du 
temps transactionnelle et concurrente, c'est-a-dire accedee par plusieurs utilisateurs simulta- 
nement). C'est le cas generalement des services metiers et des DAO. 
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La portee prototype est utilisee pour des objets a usage unique ou ne pouvant etre accedes de 
facon concurrente (on cree done un objet pour chaque utilisation). Les actions (controleurs) 
des frameworks Web Web Work et Struts 2 sont des exemples de tels Beans. 

Pour un Bean prototype, une nouvelle instance est creee a chaque reference. Une reference 
correspond a un appel direct de la methode getBean, mais aussi a une reference d'injection de 
collaborate urs. Cela signifie que si un Bean prototype est injecte trois fois, trois instances 
differentes seront creees. 

Portees de type Web 

Les portees de type Web, comme leur nom Findique, ne sont utilisables que dans le contexte 
d'une application Web. Elles ne sont de surcroit valables que pour les implementations 
d'Appl i cati onContext supportant le mode Web. 

Nous verrons au chapitre 3 comment initialiser un tel contexte d' application. 

Le support des portees de type Web necessite une activation. Dans une application Spring Web 
MVC, F activation est automatique. L activation explicite peut etre faite de deux facons differentes. 

La premiere consiste a positionner un ecouteur dans le fichier web.xml d'une application Web 
(conteneur de Servlet 2.4 ou plus) : 

<web-app> 
(...) 

<1 i stener> 

<1 i stener-cl ass> 

org. spri ngf ramework. web. context . request. RequestContextLi stener 

</l i stener-cl ass> 
</l istener> 
(...) 
</web-app> 

La seconde consiste a positionner un filtre pour les conteneurs de Servlet 2.3 : 

<web-app> 
(...) 
<filter> 

<f i 1 ter-name>requestContextFi 1 ter</f il ter-name> 
<f i 1 ter-cl ass> 

org.springframework.web.filter.RequestCon text Filter 
</f i 1 ter-cl ass> 
</filter> 
<filter-mapping> 

<f i 1 ter-name>requestContextFi 1 ter</f i 1 ter-name> 
<url -pattern>/*</url -pattern> 
</filter-mapping> 
(...) 
</web-app> 
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L'interet des portees de type Web est de disposer de Beans pleinement dedies a une requete, 
une session ou une session globale HTTP. Ces Beans peuvent etre manipules sans risque 
d'interferences avec d'autres requetes ou sessions simultanees. 

L'avantage d'un Bean de portee Web est sa capacite a etre manipule et smtout injecte comme 
un Bean de n'importe quelle portee. Nous mettons en pratique ce mecanisme au chapitre 
suivant, avec un exemple d'injection de Beans de portees differentes. 

En resume 

Nous avons vu les concepts de base de definitions et d'injection de dependances de Spring. 
Bien que relativement simples, ils donnent une autre dimension a la configuration d'une appli- 
cation ou plus exactement a la definition d'un systeme applicatif coherent, constitue d'un 
ensemble de composants collaborant entre eux. 

L' utilisation de Spring offre de nombreuses possibilites, notamment des choix entre une confi- 
guration 100 % XML ou completee par des annotations. II n'existe pas de regie absolue, mais 
plutot des styles de configuration, fondes sur le bon sens, la coherence et l'uniformite. 

La section suivante aborde une nouvelle facon de declarer des Beans, selon une approche 
100 % annotation. 

Detection automatique de composants 

La declaration dans un fichier XML est le moyen le plus courant de definir les Beans d'un 
contexte Spring. Cependant, depuis sa version 2.0, Spring est capable de detecter automati- 
quement des Beans. 

La detection passe par 1' apposition d' annotations sur les classes des Beans. II suffit de preciser 
a Spring un package dans lequel il est susceptible de trouver de telles classes, et les Beans 
seront alors instancies. 

Cette methode evite une declaration systematique sous forme XML : pour ajouter un Bean au 
contexte Spring, il suffit de creer sa classe et de l'annoter. 

Les differents types de composants 

Spring definit un ensemble d' annotations provoquant l'instanciation d'un Bean. 
Le tableau 2-4 recapitule ces annotations. 



Tableau 2-4. Annotations pour la detection de composants 



Annotation 


Description 


©Component 


Annotation generique des composants 


©Repository 


Annotation denotant un Bean effectuant des acces de donnees (par exemple DAO) 


©Service 


Annotation denotant un Bean effectuant des traitements metier 


©Control 1 er 


Annotation denotant un controleur de I'interface graphique (generalement un controleur Web) 
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Spring prone le modele composant, c'est-a-dire des objets de type boite noire effectuant des 
traitements, sans qu'une connaissance de leur fonctionnement interne ne soit necessaire. 

L' annotation ©Component permet de qualifier un tel type d'objet. Cependant, une annotation 
peut contenir des informations supplementaires pour, par exemple, qualifier le type du compo- 
sant. II s'agit la du role des annotations ©Repository, ©Servi ce et ©Control 1 er, qui permettent 
non seulement de definir un composant (et done faire que Spring le detectera automati- 
quement), mais aussi de renseigner le conteneur sur l'utilite du Bean. 

Une fois que Spring est capable de differencier les Beans qu'il contient, il peut leur ajouter du 
comportement, notamment via des post-processeurs. II est, par exemple, possible de decorer 
tous les Beans de type ©Repository afin que toute exception technique propre au systeme de 
persistance (JDBC, JPA, Hibernate, etc.) soit encapsulee sous la forme d'une exception gene- 
rique, afin de ne pas lier les couches superieures avec 1' implementation de persistance. 

II est important de noter que les annotations de composants peuvent aussi etre utilisees pour 
des Beans configures via XML. Elles servent seulement a caracteriser la nature des Beans, 
pour beneficier, par exemple, de decorations potentielles. 

Parametrages pour la detection automatique 

La detection automatique de composants s'effectue en deux temps. II faut d'abord definir les 
classes des composants et les annoter. II faut ensuite preciser dans le fichier XML de configu- 
ration de Spring le package dans lequel les composants doivent etre recherches. 

Prenons l'exemple de la definition des objets d'acces aux donnees (DAO) de Tudu Lists. Voici 
comment definir le DAO gerant les utilisateurs : 

package tudu. domain. dao.jpa; 

import org. springf ramework. stereotype . Repository; 
import tudu. domain. dao.UserDAO; 

©Repository 

public class UserDAOJpa implements UserDAO { 

(...) 

} 

Nous utilisons dans ce cas Fannotation ©Repository, afin de preciser a Spring qu'il s'agit 
d'objets gerant des acces aux donnees. L'annotation ©Component aurait suffi pour provoquer la 
detection, mais elle n' aurait pas eu cet apport semantique. 

La detection automatique se configure avec la balise component-scan du schema XML context : 
<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns : context="http: //www. spri ngf ramework. org/ schema /context" 
xsi : schema Location-" http://www.spr ingframework.org/schema/beans 
http: //www. spri ngf ramework. org/s enema /beans /spring- beans .xsd 
http: //www. spri ngf ramework. org/schema /con text 
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http://www.springframework.org/schenia/context/spring-context.xsd"> 
<context: component -scan base-package="tudu.domain.dao. jpa" /> 
</beans> 

Le package a analyser est precise avec Fattribut base-package. L' analyse est recursive, c'est- 
a-dire que tous les sous-packages seront aussi analyses. Cette balise active aussi un ensemble 
de fonctionnalites liees aux annotations (equivalent de la balise annotation-config). 

Dans notre exemple, nous n'avons rien precise concernant le nom du Bean dans le contexte 
Spring. Par defaut, le nom de la classe, commencant par une minuscule, est utilise comme 
nom pour le Bean. Notre Bean s'appelle done par defaut userDAOJpa. Ce nom par defaut n'est 
pas tres adapte, car il identifie immediatement 1' implementation de persistance sous- 
jacente. Nous pouvons preciser un nom en passant une valeur a 1' annotation : 

@Repository( "userDAO" ) 

public class UserDAOJpa implements UserDAO { 
(...) 

} 

Concernant le mode d'instanciation, la detection automatique cree des singletons par defaut. 
II est possible de preciser le mode d'instanciation via Fannotation ©Scope, avec en parametre 
la portee. Si nous voulons preciser explicitement que notre DAO doit etre un singleton : 

import org. springf ramework. context. annotation. Scope; 
import org. springf ramework. stereotype. Repository; 

@Repository( "userDAO" ) 
@Scope( "prototype" ) 

public class UserDAOJpaExplicitName implements UserDAO { 
(...) 

} 

Filtrer les composants a detecter 

Spring detecte par defaut toutes les classes annotees avec ©Component ou toute annotation en 
heritant. II est possible de modifier ce comportement en parametrant des filtres dans la balise 
component-scan. 

Spring fournit plusieurs types de filtres, recapitules au tableau 2-5. 

Tableau 2-5. Types de filtre pour la detection de composants 



Type de filtre 


Description 


annotation 


Lannotation precisee est apposee sur la classe du composant. 


assignable 


La classe du composant peut etre transtypee en la classe/interface precisee. 


aspectj 


La classe du composant correspond a la coupe AspectJ precisee . 


regex 


La classe du composant correspond a I'expression reguliere precisee. 



Les filtres peuvent etre ajoutes sous forme d'inclusion ou d'exclusion. 
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Nous pouvons, par exemple, a partir du package de base de Tudu Lists, vouloir detecter tous 
les DAO, mais pas les services, et ce via une expression AspectJ ( voir les chapitres 4 et 5, 
consacres a la programmation orientee aspect pour plus d' informations sur cette syntaxe) : 

<context : component -scan base-package="tudu"> 
<context : i ncl ude-f i 1 ter type="aspectj" 

expression="tudu. .*DA0*" /> 
<context :excl ude-f i Iter type="aspectj" 

expression="tudu. .*Service*" /> 

</context: component -scan> 

Creer sa propre annotation de composant 

Pour definir son propre type de composant, il suffit de creer une annotation heritant de ©Component. 

Pour une version Swing de Tudu Lists, les interfaces graphiques seraient des classes Java, 
gerees par Spring. Elles pourraient utiliser F annotation suivante : 

package tudu. stereotype; 

import java.l ang. annotation. Documented; 

import java.l ang. annotation. El ementType; 

import java.l ang. annotation. Retention; 

import java .1 ang. annotation. Retention Pol icy; 

import java.l ang. annotation. Tar get ; 

import org. springf ramework. stereotype .Component ; 

©Target ( {El ementType. TYPE}) 
©Retenti on( Retenti onPol i cy. RUNTIME) 
©Documented 
©Component 

public ©interface View { 

String valueO default ""; 

} 

Cette annotation a exactement le meme comportement que les autres annotations de composants 
issues de Spring. Lecran de gestion des Todos pourrait etre declare de la maniere suivante : 

package tudu. swing. stereotype; 
import tudu. stereotype. View; 
©View 

public class TodoView { 
(...) 

} 

Apposer cette annotation permet non seulement la detection automatique des vues, mais 
renseigne sur Futilite du Bean. 
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Quand utiliser la detection automatique ? 

La detection automatique de composants permet d'economiser beaucoup de code XML. Elle 
impose aussi Futilisation des annotations pour l'injection de dependances, par exemple avec 
©Autowi red. 

Une configuration Spring peut done etre totalement faite avec des annotations. Cependant la 
detection automatique presente l'inconvenient de figer la configuration, en precisant, par 
exemple, le nom du Bean directement dans la classe. 

Lapproche XML a Favantage d'etre centralisee : on a ainsi facilement une image de notre 
systeme. Son cote declaratif permet en outre une meilleure reutilisabilite des classes. 

On evite generalement la configuration complete d'une application avec la detection automa- 
tique. Ses principaux avantages sont vite rattrapes par des filtres et des qualifications 
d'autowiring fastidieuses des que les dependances deviennent un tant soit peu complexes. 

Une bonne pratique consiste a declarer les services et DAO avec une ligne XML et d'effectuer 
l'injection de dependances via de l'autowiring. Les controleurs Web peu vent quant a eux faire 
l'objet de detection automatique. II ne s'agit toutefois la que d'une indication, pas d'une regie 
absolue. 



Acces au contexte d'application 

Tout Bean declare dans un contexte d'application Spring peut se voir injecter des ressources 
liees au conteneur s'il implemente certaines interfaces. Un composant bien concu ne devrait 
normalement pas avoir besoin de ce genre d' artifice, mais cela s'avere parfois necessaire pour 
une integration poussee avec le conteneur ou pour profiter de services qu'il fournit. 

Spring propose un ensemble d'interfaces qui peuvent etre implementees par tout Bean et 
dont 1' implementation provoque le cas echeant l'injection automatique d'une ressource du 
conteneur. 

Chaque interface definit un modificateur permettant d'effectuer l'injection. Ce modificateur est 
appele apres F initialisation des proprietes du Bean, mais avant les methodes d'initialisation. 

Le tableau 2-6 recense ces interfaces. 



Tableau 2-6. Interfaces pour I'acces aux ressources du conteneur 



Interface 


Ressource correspondante 


BeanNameAware 


Le nom du Bean tel qu'il est configure dans le contexte. 


BeanFactoryAware 


La BeanFactory du conteneur 


Appl l'cationContextAware 


Le contexte d'application lui-meme 


MessageSourceAware 


Une source de messages, a partir de laquelle des messages peuvent etre recuperes via une cle. 


Appl 1 ca t ion Event Publ i sher- 
Aware 


Un editeur d'evenements, a partir duquel le Bean peut publier des evenements dans le contexte. 


ResourceLoaderAware 


Un chargeur de ressources externes, pour, par exemple, recuperer des fichiers 



Le conteneur leger de Spring 

Chapitre 2 



Certaines de ces interfaces (MessageSourceAware et ApplicationEventPublisherAware) feront 
l'objet d'une etude dans des sections dediees de ce chapitre et au chapitre 3, consacre aux 
concepts avances du conteneur. 

Notons que puisqu'un Appl icationContext implemente les interfaces MessageSource, 
ApplicationEventPublisher et ResourceLoader, le fait d'implementer seulement Finterface 
ApplicationContextAware permet d'avoir acces a l'ensemble de ces services. II est toutefois 
preferable de limiter les possibilites d'un Bean en se contentant du minimum et done d'imple- 
menter juste Finterface necessaire. 

Afin d'illustrer notre propos, nous allons implementer Finterface BeanNameAware, permettant a 
un Bean de connaitre son nom dans le contexte Spring. Voici une classe desireuse de connaitre 
son nom : 

import org. spring-framework. beans. factory. BeanNameAware; 
public class HarryAngel implements BeanNameAware { 

private String beanName; 
(...) 

public void setBeanName(String name) { 
this. beanName = name; 

} 

} 

Nous pouvons declarer notre Bean en XML : 

<bean id="harryAngel " class="splp. aware. HarryAngel " /> 

La valeur harryAngel sera done passee en parametre de setBeanName, permettant au Bean de 
connaitre son identite. 

Les interfaces d' acces aux ressources du contexte sont generalement implementees par des 
Beans tres proches de 1' infrastructure technique du conteneur leger. Etant donne que l'imple- 
mentation de ces interfaces lie le Bean a l'API Spring, voire meme au fonctionnement du 
conteneur leger, elle doit etre evitee pour les classes purement applicatives. 



Les post-processeurs 

Un post-processeur est un Bean specifique capable d'influer sur le mode de creation des 
Beans. Le principe de post-processeur constitue done un point d' extension du conteneur leger 
de Spring qui permet d'en modifier facilement les logiques de creation, de configuration et 
d'injection. 
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II existe deux types de post-processeurs dans Spring : 

• BeanPostProcessor : agit directement sur les Beans. Un BeanPostProcessor est done capable 
de modifier un Bean ou de faire des verifications sur un Bean deja initialise. 

• BeanFactoryPostProcessor : agit sur les definitions des Beans. Un BeanFactoryPost- 
Processor ne travaille done pas sur un Bean, mais sur les metadonnees qui le definissent 
avant sa creation. 

Les post-processeurs servent principalement a effectuer des verifications sur la bonne configu- 
ration des Beans ou a effectuer des modifications de facon transverse. Une simple declaration 
dans un contexte Spring permet de les activer (ils sont detectes automatiquement). 



Le post-processeur de Bean 

Un post-processeur de Bean est appele pendant le processus de creation de tout Bean. L' inter- 
face BeanPostProcessor contient deux methodes, appelees respectivement avant et apres les 
methodes d'initialisation des Beans. Les methodes d' initialisation correspondent a des methodes 
parametrees par l'utilisateur et appelees apres l'injection des proprietes des Beans. 

Voici une implementation tres simple de BeanPostProcessor : 
import java . uti 1 . Date ; 

import org. springf ramework. beans. Beans Except ion ; 

import org. springf ramework. beans .factory .config. Bean Post Processor; 

import tudu. domain. model .User; 

public class Simpl eBeanPostProcessor 

implements BeanPostProcessor { 

public Object postProcessBeforeInitialization( 

Object bean, String beanName) throws BeansException { 
if(bean instanceof User) {<— O 

((User) bean) .setCreationDate(new Date());<— Q 

} 

return bean; 

} 

public Object postProcessAfterInitialization( 

Object bean, String beanName) throws BeansException { 
return bean;<— Q 

) 

} 

Cette implementation ne modifie que les utilisateurs de Tudu Lists (0) et positionne leur date 
de creation a la date du jour (Q). Cela s'effectue avant l'appel potentiel par Spring d'une 
methode d'initialisation. Aucune operation n'est effectuee apres la creation du Bean (©). 

Chacune des methodes doit retourner une valeur, en general le Bean qui a ete passe en para- 
metre, mais il est possible de retourner une autre instance ou la meme instance, mais decoree. 
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II suffit de declarer le post-processeur dans le contexte d'application pour qu'il prenne effet et 
modifie, par exemple, le Bean user : 

<bean class="splp.postproc.SimpleBeanPostProcessor" /> 
<bean id="user" class="tudu. domain. model .User" /> 

Si Ton utilise une BeanFactory, tout BeanPostProcessor doit etre enregiste de facon program- 
matique. 

L'ordre d'execution des BeanPostProcessor peut etre parametre. Spring se fonde sur l'imple- 
mentation de l'interface Ordered ou de l'utilisation de l'annotation ©Order. Cette methode 
consiste a preciser une valeur donnant une indication a Spring pour trier la pile de post- 
processeurs. 

Les BeanPostProcessor fournis dans Spring implementent Ordered, et il est possible de para- 
meter la propriete order. 

Voici les post-processeurs les plus couramment utilises dans Spring : 

• CommonAnnotationBeanPostProcessor : active la detection des annotations de la JSR 250, 
utilisees notamment pour les methodes d'initialisation, de destruction et l'autowiring. 

• RequiredAnnotationBeanPostProcessor : active la detection de l'annotation ©Required, qui 
precise les proprietes obligatoires dans un Bean. 

Le post-processeur de fabrique de Bean 

Le post-processeur de fabrique de Bean est utilise pour modifier la configuration de la fabri- 
que de Bean suite a sa creation. Ce type de post-processeur est done capable d'agir sur la defi- 
nition des Beans, e'est-a-dire avant leur creation, par exemple, pour modifier des parametes 
de configuration. 

Voici une implementation de BeanFactoryPostProcessor qui affiche dans la console le nombre 
de Beans definis dans le contexte : 

import org. springf ramework. beans . Beans Except i on ; 
import org. sp ringf ramework. beans. factory. config.** 

BeanFactoryPostProcessor; 
import org. sp ringf ramework. beans. factory. config.** 

Conf igurabl el_i stabl eBean Factory; 

public class Simpl eBeanFactoryPostProcessor 

implements BeanFactoryPostProcessor { 

public void postProcessBeanFactory ( 

Conf igurabl e Li stabl eBean Factory bean Factory ) 
throws BeansException { 
System. out. println( 
beanFactory.getBeanDefinitionCount( )+" bean(s) defini(s)" 

); 

} 

} 
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Dans un Appl icationContext, il suffit de declarer en tant que Bean un BeanFactory- 
PostProcessor pour qu'il soit active. Pour une BeanFactory, il faut l'ajouter de facon program- 
matique. 

L'ordre d'execution des BeanFactoryPostProcessors dans un contexte Spring suit les merries 
regies que celui des BeanPostProcessor. 

En pratique, il est rare d'implementer son propre BeanFactoryPostProcessor. Spring propose 
des implementations pretes a l'emploi. L'une d'elles (detaillee au chapitre 3) permet, par 
exemple, d'externaliser des elements de configuration dans des fichiers de proprietes. 



Support de I'internationalisation 

L'internationalisation (ou H8n, puisqu'il y a dix-huit lettres en le premier caractere et le 
dernier) des applications Java est assuree via des fichiers de proprietes (un par langue) asso- 
ciant une cle et un message. En fonction de la localisation de l'application, la JVM selec- 
tionne le fichier de proprietes adequat, qui doit se trouver dans le classpath. 

Elle se fonde pour cela sur le nom du fichier, qui doit etre suffixe par le code ISO du pays 
(par exemple messages_FR.properties pour les messages en francais). Si le fichier de 
proprietes ne specifie pas de code ISO, il est considere comme le fichier par defaut qui sera 
utilise si l'application n'est pas en mesure d' identifier la langue dans laquelle elle doit fonc- 
tionner. 

Pour en savoir plus sur le format de ces fichiers, nous invitons le lecteur a lire la javadoc 
concernant la classe java . uti 1 . ResourceBundl e, utilisee pour acceder aux messages. 

Spring propose un support pour l'internationalisation d'une application. Ce systeme simple 
mais efficace est utilise par differents projets du portfolio Spring (Spring MVC et Spring Web 
Flow), mais il peut tout aussi bien etre utilise pour internationaliser les messages (generate - 
ment d'erreur) d'une couche metier. 

Dans Spring, la notion equivalente d'un ResourceBundl e est MessageSource. Spring en propose 
un ensemble d'implementations, dont la plus courante est ResourceBundl eMessageSource. 
Celle-ci permet notamment d'agreger plusieurs fichiers. 

Un contexte d' application implementant 1' interface MessageSource, il peut aussi permettre de 
recuperer des messages. Par defaut, le contexte d'application ne contient aucun message. S'il 
contient un Bean de type MessageSource s'appelant messageSource, ce dernier est utilise pour 
resoudre les messages qui sont demandes au contexte. 

Voici comment declarer un MessageSource se fondant sur deux fichiers pour recuperer ses 
messages : 

<bean id="messageSource" 

cl ass="org.springf ramework. context. support 
ResourceBundl eMessageSource" > 
<property name="basenames"><— Q 
<list> 

<val ue>spl p. i 18n .messages</val ue><— Q 
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<val ue>spl p. i 18n .except ions</val ue> 
</list> 
</property> 
</bean> 

Nous utilisons la propriete basenames (0), a laquelle nous passons une liste de chaines de 
caracteres. Si nous n'avions utilise qu'un fichier de proprietes, nous aurions pu utiliser la 
propriete basename et lui passer une valeur simple (attribut value). Les chaines de caracteres 
definissant les fichiers de proprietes suivent les merries regies que pour les ResourcesBundles. 
La valeur du repere Q fait done reference au fichier messages.properties se trouvant dans le 
package splp.ilSn. 

Voici le contenu du fichier messages.properties : 
] welcome. to. tudu.lists=Wel come to Tudu Lists! 

Nous pouvons utiliser directement le contexte d' application pour recuperer un message : 

String welcome = context. getMessaget 
"welcome. to. tudu. lists", null .locale 

); 

Le parametre 1 ocal e (de type java . uti 1 . Local e) specifie la localisation a utiliser pour selec- 
tionner la langue du message. S'il vaut nul 1 , le choix de la langue est realise par la JVM. 



Comment connaitre la localisation dans un service metier ? 

Dans une application internationalisee, il est important de remonter des messages dans la langue de I'utili- 
sateur. Pour une application Web, la langue est generalement connue a partir d'en-tetes se trouvant dans 
la requete HTTP (et correspondant done aux reglages du navigateur de I'utilisateur). Ces en-tetes ne sont 
accessibles que par les couches superieures de I'application. Celles-ci doivent d'une maniere ou une autre 
rendre la localisation de I'utilisateur accessible aux couches inferieures (metier et parfois persistance). II ne 
faut en aucun cas se fonder sur la methode statique Local e.getDefaul t, qui retourne la localisation du 
serveur ! Une solution elegante consiste a stacker la localisation dans un Bean de portee session HTTP 
qui pourra etre injecte dans les Beans necessitant d'interagir avec le contexte utilisateur. (Ce mecanisme 
est illustre au chapitre 3.) 



Dans l'appel precedent, si le MessageSource n'est pas en mesure de resoudre le message qu'on 
lui demande, il lance une NoSuchMessageException. Ce comportement peut etre evite en 
passant une valeur par defaut pour le message : 

String msg = context. getMessage( 

"unknown. message" , nul 1 , "An unknown message!", locale 

); 

Dans les deux appels presentes, la valeur nul 1 est passee au second parametre. Celui-ci correspond 
a un tableau de parametres qui peut etre passe au message. Encore une fois, le comportement 
correspond a celui des ResourceBundl es. Prenons le message suivant dans exceptions.properties : 



| register. user. al ready. exists=User login "{0}" already exists. 
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La valeur {0} correspond au premier element du tableau de parametres. Nous pouvons done 
inclure dynamiquement le nom de Futilisateur deja existant : 

String message = context. getMessage( 
" register. user. al ready .exists" , 

new 0bject[] {user .getl_ogin( ) } , 

1 ocal e 

); 

Jusqu'ici, arm d'illustrer le mecanisme de resolution des messages, nous avons utilise le 
contexte d'application en tant que MessageSource. Cependant, dans une application, le 
contexte d'application n'est pas (et ne doit pas !) etre directement reference depuis un Bean 
applicatif (un service metier, un controleur). II est preferable de disposer d'une propriete 
MessageSource dans les Beans necessitant la resolution de messages. Cette propriete est alors 
injectee lors de la creation du Bean. 

Deux solutions s'offrent a nous pour injecter le MessageSource dans un Bean. La premiere 
consiste a implementer Finterface MessageSourceAware, afin que le MessageSource soit automa- 
tiquement injecte : 

import org. springf ramework. context. MessageSource; 
import org. springf ramework. con text. MessageSourceAware; 

public class UserManagerlmpl implements MessageSourceAware { 
private MessageSource messageSource ; 

public void setMessageSource(MessageSource messageSource) { 
thi s .messageSource = messageSource; 

} 

public void createUser(User user) 

throws UserAlreadyExistsException { 
(...) 

if(userAl readyExists) { 
throw new UserAl readyExistsException( 
messageSource. getMes sage ( 

"register. user. already. exists", 
new 0bject[] {user .getl_ogin( ) } , 
locale 

)); 

} 

} 

(...) 

} 

Le Bean peut alors etre declare sans preciser Finjection du MessageSource : 
<bean id="userManager" cl ass="tudu. service. impl . UserManagerlmpl "/> 
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La seconde solution consiste a declarer une propriete MessageSource et a faire une injection 
explicite. Le service metier n'implemente plus MessageSourceAware : 

public class UserManagerlmpl { 

private MessageSource messageSource ; 

public void setMessageSource(MessageSource messageSource) { 
thi s .messageSource = messageSource; 

} 

(...) 

} 

Le Bean est alors configure de la maniere suivante : 

<bean id="userManager" class=" tudu. service. impl .UserManagerlmpl "> 

<property name="messageSource" ref="messageSource" /> 
</bean> 

Les deux solutions sont relativement equivalentes. La premiere est plus intrusive, a cause de 
1' implementation d'une interface Spring, mais l'injection est automatique. La seconde solu- 
tion n'impose pas 1' implementation de l'interface et represente done une forme plus radicale 
du modele d'injection de dependances. 

II existe en fait une troisieme solution qui consiste a utiliser Fautowiring. Meme si cette solu- 
tion fera bondir certains puristes, elle fonctionne tres bien s'il n'existe qu'un seul 
MessageSource dans le contexte d' application. II suffit pour cela d'annoter la propriete dans la 
classe : 

public class UserManagerlmpl { 
@Autowi red 

private MessageSource messageSource; 
(...) 

} 

Le Bean peut ensuite etre declare sans preciser explicitement d'injection, mais sans oublier 
d'activer la detection de 1' annotation d'autowiring. 



Conclusion 

Ce chapitre a introduit les principes de base du conteneur leger de Spring. Vous etes mainte- 
nant capable de configurer un systeme de Beans complexe aussi bien en XML qu'avec des 
annotations. 

Nous avons aborde les notions d' infrastructure du conteneur, notamment les post-processeurs, 
qui permettent d'effectuer des traitements systematiques sur les Beans et dont Spring fournit 
de nombreuses implementations a des fins multiples. 
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Le support de l'internationalisation a aussi ete detaille. II permet d'internationaliser la partie 
metier d'une application et est fortement utilise dans des frameworks afferents a Spring 
(Spring MVC, Spring Web Flow, etc.). 

Les concepts traites dans ce chapitre permettent d'adresser un grand nombre des problemati- 
ques de configuration d'une application d'entreprise. Cependant, pour tirer pleinement parti 
de la puissance du conteneur leger de Spring et, surtout, rendre la configuration d'une applica- 
tion aussi souple que possible, il peut s'averer necessaire de connaitre des techniques supple- 
mentaires. 

C'est le propos du chapitre 3, qui traite de concepts avances et constitue une plongee appro- 
fondie dans les mecanismes du conteneur leger de Spring. 



3 

Concepts avarices 
du conteneur Spring 



Nous avons introduit au chapitre precedent les concepts essentiels pour l'utilisation du conte- 
neur leger de Spring. Nous abordons ici des concepts avances, arm de faire beneflcier nos 
applications du meilleur du conteneur leger. 

Ce chapitre approfondit les notions d' injection et de definition des Beans, avec notamment 
l'injection de Beans de portees differentes, la verification des dependances ou la definition 
abstraites de Beans. Nous verrons aussi comment le conteneur peut agir sur les Beans lors de 
leur creation ou de leur destruction. 

Nous detaillerons aussi F infrastructure que le conteneur met a la disposition des applications 
pour la gestion de ressources externes et la publication d'evenements. Nous finirons par le 
pont que propose Spring entre Java et les langages dynamiques tels que Groovy, afin d'utiliser 
les outils les plus adaptes pour les differentes problematiques d'une application d'entreprise. 

Ce chapitre contient enfin conseils et bonnes pratiques d' utilisation du conteneur Spring, qui 
apporteront beaucoup a la souplesse et a la modularite de vos applications. 



Techniques avancees d'injection 

Spring permet de repondre a des besoins complexes en termes d'injection de dependances. 
II offre la possibilite de faire cohabiter des Beans de portees differentes pour, par exemple, 
faciliter la propagation d'un contexte au travers des couches d'une application. II permet aussi 
de verifier que les dependances des Beans sont assignees, afin que ceux-ci soient correctement 
initialises et pleinement fonctionnels. 
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Injection de Beans de portees differentes 

La notion de portee a ete introduite au chapitre precedent. Elle permet d' adapter le cycle de 
vie d'un objet controle par Spring a l'utilisation qui en est faite. 

Ainsi, un service metier ou un DAO sont des singletons, parce que leur etat n'est pas modifie 
apres leur initialisation et qu'ils peuvent des lors etre utilises de facon concurrente sans aucun 
risque. En revanche, les objets a usage unique ou ne supportant pas les acces concurrents ont la 
portee « prototype » : chaque fois qu'ils sont references, le conteneur cree une nouvelle instance. 

Spring introduit aussi les portees Web, qui, grace a l'injection de dependances, permettent 
d'utiliser des objets de facon completement transparente et sure dans un contexte bien deli- 
mite (la requete ou la session HTTP). 

Cependant, Finteret de certaines portees, notamment les portees Web, serait limite si nous ne 
pouvions beneficier de l'injection de dependances entre des Beans de portees differentes. 

Prenons le probleme recurrent de propagation du contexte utilisateur a travers les couches metier 
et d' acces aux donnees. Generalement, dans une application Web, le contexte utilisateur (identi- 
fiant, droits, informations diverses, etc.) est contenu dans une variable de la session HTTP. Ce 
contexte doit etre transmis aux couches inferieures pour, par exemple, verifier des droits. 

Une solution elementaire consiste a passer le contexte utilisateur en parametre de chacune des 
methodes en ayant besoin. Cette solution pollue malheureusement fortement et parfois syste- 
matiquement les signatures des methodes. 

Voici un exemple de methode dans un service metier ayant besoin de faire une verification sur 
le profil de l'utilisateur courant : 

public class BusinessService { 
public void updateImportantData( 

InfoUtilisateur infoUtilisateur ) { 

i f (can Do Import an tThings( i nfoLIti 1 i sateur) ) { 
// mise a jour de donnees importantes 

} 

} 

(...) 

} 

Les informations concernant l'utilisateur sont explicitement passees en tant que parametres de la 
methode, et cela s'averera necessaire pour toute methode necessitant une telle verification. Cette 
solution est particulierement intrusive, car elle modifie fortement F interface du service metier. 

Une solution plus avancee pour la transmission du contexte utilisateur consiste a le mettre 
dans une variable locale au fil d'execution (thread-locale, technique adoptee par Spring pour 
propager les transactions ou les sessions des outils de mapping objet-relationnel). Le contexte 
utilisateur est alors accessible, par exemple, via une methode du service qui encapsule la 
mecanique de recuperation : 

public class BusinessService { 

public void updateImportantData( ) { 
if(canDoImportantThings(getInfoUtilisateur() )) { 
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II mise a jour de donnees importantes 

} 

} 

(...) 

} 

La methode getlnf oUti 1 i sateur n'est pas detaillee mais elle correspondrait a la recuperation 
d'une variable thread-locale qui aurait ete positionnee par exemple dans la couche presenta- 
tion. Cette solution peut toutefois s'averer complexe a mettre en place, et une mauvaise imple- 
mentation peut entrainer des problemes techniques, comme des ruites de memoire. De plus, la 
testabilite du service metier est rendue difficile, car la variable thread-locale doit etre posi- 
tionnee pour qu'il soit operationnel, meme dans un contexte de test. 

II est possible d'adresser ce probleme de propagation du contexte utilisateur de facon tres 
elegante avec Spring, tout en gardant la souplesse de l'injection de dependances. Spring est 
capable d'injecter des Beans de portee de type Web dans des singletons. Dans notre exemple, 
nous aurions done un service metier (de portee singleton) se voyant injecter le contexte utili- 
sateur, qui, lui, serait de portee session. 

Le service metier peut etre declare avec une propriete i nf oUti 1 i sateur : 
public class BusinessService { 

private InfoUtil i sateur infoUtili sateur; 

public void updateImportantData( ) { 

if (canDoImportantThingsO'nfolltil i sateur) ) { 
// mise a jour de donnees importantes 

} 

} 

(...) 

} 

Le service metier utilise les informations utilisateur pour verifier si Futilisateur a les droits de 
mettre a jour des donnees importantes. Du point de vue de la classe Java, le fonctionnement 
est simple et naturel : le service metier suppose que sa propriete i nf oUti 1 i sateur correspond 
bien a Futilisateur en cours. 

Voici la configuration XML correspondante pour une application Web : 
<bean id=" business Service" class="spl p. sample. BusinessService") 

<property name="infoUtilisateur" ref="infoUtilisateur" /> 
</bean> 

<bean id="infoUti 1 i sateur" cl ass="spl p.sampl e. InfoUti 1 i sateur" 
scope="session"> 
<aop: scoped-proxy /> 

</bean> 
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Le service metier est, par defaut, declare en tant que singleton et se voit injecter le Bean 
infoUtilisateur. Celui-ci est declare avec la portee session. Nous avons ici un exemple 
d'injection de dependances entre Beans de portees differentes. II n'y a qu'une seule instance 
du service metier pour toute l'application ; en revanche, il existera autant d'instances d'infor- 
mations utilisateur qu'il y a d'utilisateurs connectes (avec une session HTTP valide). 

Chacun des utilisateurs va appeler le meme service metier, mais, au sein de celui-ci, il faut que 
Finstance des informations utilisateur corresponde au contexte Web de cet utilisateur. C'est la 
que Spring intervient en ayant injecte plus qu'une simple instance d'lnfoUtil i sateur. 

En effet, la balise bean d'infoUtilisateur contient la balise scoped-proxy du schema aop. 
Cette balise indique a Spring que le Bean i nf oUti 1 1 sateur doit etre instancie puis « decore », 
c'est-a-dire que Spring va ajouter du comportement a ce Bean. Le comportement consiste en 
un « aiguillage » vers une instance d'infoUtilisateur correspondant a la session HTTP 
courante, et ce chaque fois qu'une methode du Bean est appelee. 

Cette mecanique est totalement prise en charge par Spring ; elle est done transparente pour le 
service metier. Si nous avons la curiosite de faire afficher le nom de la classe de la propriete 
i nf oUti 1 i sateur du service metier, nous obtenons la sortie suivante : 



splp.sample.InfoUtilisateur$$EnhancerByCGLIB$$82fb3d63 



Cette sortie signifie que Spring a utilise la bibliotheque CGLIB pour enrichir notre instance 
d'infoUtilisateur. 



Decoration et utilisation d'interfaces 

La decoration (ou ajout de comportement) de Beans dans Spring passe par I'utilisation d'un objet proxy se subs- 
tituant a I'objet cible. C'est ce proxy qui implemente le nouveau comportement. Java propose en natif le meca- 
nisme de proxy, mais il faut alors que I'objet cible implemente une interface. II est possible d'utiliser des proxy 
pour des objets n'implementant aucune interface (comme dans notre exemple de Bean de portee session), mais 
Spring a recours alors a la bibliotheque CGLIB pour generer le proxy et decorer I'objet cible. II faut done veiller a 
ajouter le JAR de CGLIB au classpath d'une application si des Beans a decorer n'implementent pas d'interfaces. 



Un des avantages de cette solution est qu'elle rend le service metier totalement indepen- 
dant du contexte dans lequel il est utilise (Web ou autre). Si Ton souhaite effectuer des 
tests unitaires sur ce service, il suffit de lui injecter manuellement une simple instance 
d' Inf oUti 1 i sateur : cela sera suffisant pour lui creer un contexte pleinement fonctionnel. 

Verification des dependances 

Spring offre la possibilite de s'assurer que les proprietes des Beans ont ete initialisees. Comme 
pour l'autowiring, la verification des dependances se regie au niveau du tag bean, grace au para- 
metre dependency-check, permettant ainsi de cibler I'utilisation de cette fonctionnalite. 

La verification des dependances peut prendre l'une des trois formes suivantes : 

• simple: seules les proprietes simples (int, float, etc.) et les structures de donnees sont verifiees. 
Les collaborateurs ne le sont pas. 
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• objects : seuls les collaborateurs sont verifies. 

• all : combinaison des deux formes precedentes. 

Si nous reprenons le Bean userManager, nous pouvons enclencher la verification des depen- 
dances de la maniere suivante : 

<bean id="userManager" cl ass="tudu. service. impl .UserManagerlmpl " 
dependency -check="objects"> 

<property name="userDAO" ref="userDAO" /> 
</bean> 

La verification des dependances avec l'attribut dependency-check agit sur l'ensemble des 
proprietes. II est parfois utile de n'agir que sur certaines proprietes : on utilise alors 
l'annotation ©Required, qui, apposee sur une propriete, indique a Spring qu'elle est obli- 
gatoire. 

Comme pour l'annotation @Autowi red, il est necessaire d'activer la detection des annotations 
sur les Beans Spring. On peut le faire de deux facons differentes. La premiere revient a utiliser 
la balise annotation-config du schema context : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns : context="http: //www. spri ngf ramework. org/ schema /context " 
xsi : schema Location-" http://www.spr ingframework.org/schema/beans 
http: //www. spri ngf ramework. org/schema /beans /spring- beans .xsd 
http: //www. spri ngf ramework. org/schema /con text 

http://www.springframework.org/schema/context/spring-context.xsd"> 
<context:annotation-config /> 
</beans> 

La seconde consiste a positionner un BeanPostProcessor : 

<bean class-"org. spri ngf ramework. beans. factory. annotation. 
Requi redAnnotationBean Post Processor "/> 

Les modificateurs des proprietes d'une classe peuvent ensuite etre annotes avec ©Required 
pour preciser a Spring qu'ils sont obligatoires : 



(...) 

import org. spri ngf ramework. beans. factory. annotation. Requi red; 
(...) 

public class UserManagerlmpl implements UserManager { 



private UserDAO userDAO; 



@Requi red 

public void setUserDAO(UserDAO userDAO) { 
this. userDAO = userDAO; 
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} 

(...) 

) 

La verification des dependances par Spring ne doit pas etre vue comme une solution unique a 
F initialisation incorrecte d'un Bean. Elle n'exclut pas une verification programmatique de la 
coherence de l'etat, par exemple dans une methode d' initialisation (nous verrons par la suite 
comment appeler de telles methodes). 



Techniques avancees de definition 

Les facons les plus classiques de definir des Beans dans le conteneur leger de Spring consistent a 
les declarer en XML ou en utilisant la detection automatique, grace aux annotations. 

II est possible de completer ces approches pour, par exemple, reutiliser des elements de 
configuration avec la definition abstraite de Beans ou creer des Beans avec des methodes 
personnalisees d'instanciation. 

Definitions abstraites de Beans 

Pour remedier au probleme de duplication de lignes de configuration d'un Bean a un autre, 
Spring propose un mecanisme d'heritage de configuration. Ce dernier permet de definir des 
Beans abstraits, c'est-a-dire qui ne sont pas instancies par le conteneur, de facon a concenter 
les lignes de configuration reutilisables. 

Les definitions abstraites sont particulierement utiles pour les Beans ayant un ensemble de 
proprietes communes, typiquement des services metier ou des DAO. 

Prenons, par exemple, la definition abstraite d'un DAO fonde sur Hibernate : 

<bean id="abstractDAO" abstract-"true" > 

<property namemini si te=" hi bernateTempl ate" ref="hibernateTempl ate" /> 
</bean> 

II n'est pas utile de preciser un type de Bean puisque celui-ci n'est pas destine a etre instancie 
par le conteneur. Nous pouvons ensuite definir un DAO s'appuyant sur cette definition : 

|<bean id-"propertyDAO" parent="abstractDAO" 
cl as s="tudu.domain.dao. hibernate. Property DAOHibernate" /> 

Dans ce cas, l'utilisation d'une definition abstraite permet de s'affranchir de la configuration 
de la propriete hi bernateTempl ate. II faut bien sur que tout Bean heritant de cette definition 
dispose de cette propriete. 

Notons que l'heritage de configuration ne necessite pas de structure d'heritage au niveau objet 
(nos DAO sont independants les uns des autres). Ce mecanisme est strictement interne a la 
configuration des Beans. 
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Support de nouveaux types pour les valeurs simples 

Les classes utilisees comme des types de proprietes n'ont pas forcement toutes vocation a etre 
gerees sous forme de Beans par le conteneur leger. II peut etre plus interessant de les traiter 
comme des valeurs simples, initialisees via une chaine de caracteres. 

Inconnus de Spring, ces types doivent etre accompagnes d'un transcodeur, a meme de faire la 
conversion entre la chaine de caracteres et les attributs du type. 

Nous devons done creer un editeur de proprietes, un concept issu du standard JavaBeans, 
correspondant a notre transcodeur. C'est ce concept qu'utilise Spring pour supporter les 
differents types de valeurs simples que nous avons vus precedemment. 

Imaginons que nous voulions pouvoir assigner directement des dates dans les fichiers XML de 
Spring : 

<bean id="user" class="tudu. domain. model .User"> 

<property name="creationDate" val ue="2008-10-28" /> 
</bean> 

Malheureusement, cela n'est pas possible par defaut. Spring n'est pas capable de faire la 
conversion chaine vers date, car il ne dispose pas d'un PropertyEditor pour la classe 
java . uti 1 . Date. 

Pour rendre cela possible, nous devons dans un premier temps definir cet editeur : 
package splp.propertyeditors; 

import java .beans . Property Ed i torSupport ; 
import java .text . ParseException ; 
import java .text .Si mpl eDate Format ; 
import java. util .Date; 

public class DatePropertyEditor extends PropertyEditorSupport { 
private String pattern = "yyyy-MM-dd" ; 
public void setAsText(String text) 



throws IllegalArgumentException { 
try { 

Date date = new SimpleDateFormat(pattern) .parse(text) ; 
setVal ue(date) ; 
} catch (ParseException e) { 
throw new II 1 egal ArgumentException(e) ; 



public void setPattern(String pattern) { 
this. pattern = pattern; 
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Deliver de la classe java. beans. PropertyEditorSupport permet de s'affranchir d'un certain 
nombre de traitements. La methode qui nous interesse est setAsText, qui effectue la conver- 
sion de la chaine de caracteres (correspondant a la valeur de Fattribut val ue dans la definition 
XML) en Fobjet voulu : dans notre cas, une date. Le resultat de la conversion doit etre enre- 
gistre avec la methode setVal ue. 

Pour que Spring sache ou trouver nos editeurs de proprietes specifiques, il existe deux 
possibilites : soit Fediteur se trouve dans le meme package que le type, et son nom est alors de 
la forme TypeEditor (oil Type correspond au nom du type : dans notre exemple, DateEditor), 
soit en ajoutant ces quelques lignes dans le fichier de configuration : 

<bean class="org.springframework. beans. factory .config. 
CustomEdi torConf i gurer"> 
<property name="customEdi tors"> 
<map> 

<entry key=" java . uti 1 . Date" 

value-" splp.propertyeditors.DatePropertyEditor" /> 
</map> 
</property> 
</bean> 

Support de fabriques de Beans specifiques 

Les exemples que nous avons donnes jusqu'a present laissent au conteneur leger la charge 
d'instancier et d'initialiser directement les Beans de notre application. Dans certains cas, il 
peut etre necessaire de ne pas deleguer cette creation, afin de realiser des traitements speci- 
fiques, non exprimables via le langage XML de configuration, par exemple. 

Ce support est souvent utilise pour integrer des applications existantes non fondees sur Spring 
et 1' injection de dependances. 

Afin de repondre a ce besoin, Spring propose plusieurs methodes pour implementer des fabriques 
de Beans specifiques. 

Utilisation d'une fabrique sous forme de Bean classique 

La methode la plus simple consiste a creer une classe fabrique disposant d'une methode sans 
parametre renvoyant une instance du Bean attendu. 

Voici, par exemple, une fabrique d'utilisateurs de Tudu Lists : 

public class TuduUserFabrique { 
public User createUserO { 
User user = new User( ) ; 
// initialisation complexe. . . 
(...) 

return user; 

} 

} 
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II suffit ensuite d'indiquer la classe prealablement definie sous forme de Bean et la methode 
de fabrication dans la configuration du Bean cible grace aux parametres factory-bean et 
factory-method : 

<bean id="userFabrique" class="splp. factory. TuduUserFabrique" /> 

<bean id="user" class="tudu. domain. model .User" 

f actory-bean=" user Fabri que" factory- met hod="createUser"> 

(...) 

</bean> 

Utilisation de I'interface FactoryBean 

Une methode plus complexe consiste a implementer I'interface FactoryBean du package 
org. springf ramework. beans. factory. Cette interface est tres utilisee par Spring en interne 
pour definir des fabriques specialisees pour certains types complexes. 

Par convention, le nom des implementations de cette interface est suffixe par FactoryBean. 
Cette technique s'avere pratique pour recuperer des instances qui ne peuvent etre creees direc- 
tement avec un new. 

Pour initialiser une SessionFactory Hibernate avec Spring, nous pouvons utiliser une 
LocalSessionFactoryBean : 

<bean id-"sessionFactory" 

cl as s-" org. sp ringf ramework. orm. hi bernate3. LocalSessionFactoryBean" > 
<property name="dataSource" ref="dataSource" /> 
(...) 

</bean> 

La fabrique se declare sous la forme d'un Bean, comme avec la methode precedente, la seule 
difference etant qu'il n'est pas necessaire de specifier la fonction de creation des instances du 
Bean. En fait, la fabrique se substitue au type du Bean. 

En effet, les references a ce Bean correspondent non pas a l'instance de la fabrique, mais aux 
instances qu'elle cree. C'est la raison pour laquelle sessi onFactory est utilise comme un Bean 
classique pour l'injection de dependances : 

<bean id="hibernateTemplate" 

cl a ss=" org. springf ramework. orm. hi bernate3. Hi be rnateTempl ate"> 
<property name="sessionFactory" ref="sessionFactory" /> 
</bean> 

Si nous reprenons notre exemple precedent, la fabrique prend la forme suivante : 
import org. springf ramework. beans. factory .FactoryBean; 

public class TuduUserFactoryBean implements FactoryBean { 

public Object getObjectO throws Exception { 
User user = new User( ) ; 
// initialisation complexe... 
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(...) 

return user; 

} 

public Class getObjectType( ) { 
return User. class; 

} 

public boolean isSingleton( ) { 
return false; 

} 

} 

La methode getObject renvoie l'instance demandee a la fabrique, tandis que la methode 
getObjectType renvoie le type de Bean cree par la fabrique. La fonction isSingleton indique 
pour sa part si la fabrique cree des singletons ou des prototypes. 

Nous pouvons maintenant utiliser cette nouvelle fabrique pour creer notre utilisateur de Tudu 
Lists : 

<bean id-"user" class-"splp. factory .TuduUserFactoryBean" /> 

Notons la disparition de l'initialisation des proprietes de User. L initialisation qui doit figurer 
a la place est celle de la fabrique du Bean, et non du Bean en lui-meme. TuduUserFactoryBean 
n'ayant pas de propriete, il n'y a pas d'initialisation dans cette definition. 

En conclusion, par rapport a la methode precedente, la fabrique de Bean a ici l'entiere respon- 
sabilite de la creation de l'instance du Bean ainsi que de son initialisation. Remarquons que 
nous pouvons recuperer l'instance de la FactoryBean elle-meme en prefixant le nom du Bean 
avec &. 

Cycle de vie des Beans 

Le cycle de vie de chaque Bean comporte une naissance et une mort. Dans le cadre du conte- 
neur leger de Spring, la naissance de l'ensemble des Beans singletons s'effectue au demarrage 
de celui-ci par defaut. Cela induit un temps de chargement plus long de 1' application, mais 
presente l'avantage de s' assurer des le demarrage que la creation des Beans ne posera pas de 
probleme. 

Une fois le Bean cree et ses proprietes (ou collaborateurs) configurees, Spring peut appeler 
une methode d'initialisation parametree par le developpeur. Cette methode sera particuliere- 
ment utile pour verifier la coherence de l'etat du Bean (s'il lui manque des dependances, par 
exemple) ou effectuer une initialisation complexe. 

La mort des Beans depend de leur nature. S'il s'agit de prototypes, ceux-ci disparaissent des 
lors que plus aucun objet ne les reference et que le ramasse-miettes a fait son ceuvre. Spring ne 
conservant pas de reference en interne pour les prototypes, il n'a pas « conscience » de leur 
mort. 
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Par contre, il conserve une reference pour chaque singleton dont il a la charge. II a done 
« conscience » de leur mort, ce qui permet de realiser des traitements lorsque celle-ci survient, 
par exemple liberer des ressources. 

Le lancement (par Spring) d'une methode avant la destruction d'un Bean n'est done garanti 
que pour les singletons. 

L'exemple caracteristique d'un Bean devant reagir a son cycle de vie est un pool de 
connexions, qui va creer les connexions a son demarrage, une fois qu'il connaitra les parametres, 
et fermer ces connexions lors de sa destruction. 

Spring propose trois moyens pour appeler des methodes a la creation et a la destruction d'un 
Bean : 

• parametrage des methodes dans la configuration XML ; 

• implementation d' interfaces ; 

• utilisation d' annotations. 

Nous allons etudier chacune de ces solutions. Bien que nos exemples illustrent le lancement 
de traitements a la fois a la creation et a la destruction d'un Bean, il est possible de les confi- 
gurer de facon independante. 

Lancement des traitements via XML 

Le lancement de traitements via la configuration XML se fait en indiquant les methodes a 
executer dans la definition du Bean. Par exemple, pour le Bean suivant : 

public class BusinessService { 

public void initO { 
// initialisation 

} 

publ ic void cl ose( ) { 
// destruction 

} 

} 

Lors de la definition du Bean, nous utilisons les attributs i nit-method et destroy-method pour 
faire reference a nos methodes : 

<bean id=" business Service" cl ass-"spl p. 1 ifecycle. Business Service" 
init-method="init" destroy-method="cl ose" /> 

Cette solution est interessante, car elle est totalement declarative et ne lie pas le Bean a une 
quelconque API. En revanche, elle n'est pas completement sure : on peut oublier de configu- 
rer le lancement des methodes. De plus, la configuration Spring ne peut beneficier d'un refac- 
toring automatique (si le nom des methodes change). 
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Lancement des traitements via des interfaces 

Spring propose l'interface Initial i zi ngBean, correspondant a la creation du Bean, et l'inter- 
face DisposableBean, correspondant a sa destruction. II est possible d'implementer Fune ou 
F autre de ces interfaces ou les deux. 

Voici un Bean implementant ces deux interfaces : 

import org. spring-framework, beans, factory .DisposableBean; 
import org. springf ramework. beans .factory . Initial izi ngBean ; 

public class BusinessService 

implements InitializingBean, DisposableBean { 

public void afterPropertiesSet( ) throws Exception { 
// initialisation (methode de InitializingBean) 

} 

public void destroyO throws Exception { 
// destruction (methode de DisposableBean) 

} 

) 

La configuration XML ne differe pas de celle d'un Bean normal : 

<bean id="businessService" class-"splp.lifecycle.BusinessService"/> 

Spring detecte automatiquement si le Bean implemente InitializingBean ou DisposableBean 
et appelle alors les methodes correspondantes. 

L'avantage de cette solution est sa parfaite integration avec Spring et son cote systematique 
(Fappel est automatique). En revanche, elle est intrusive, puisqu'elle lie le Bean a l'API 
Spring. Cette solution est souvent adoptee par les classes internes a Spring et les classes destinees 
a etre utilisees via Spring. 

Lancement des traitements via des annotations 

Cette solution consiste a annoter des methodes avec les annotations de la JSR 250 (Common 
Annotations). Ces deux annotations sont ©PostConstruct et ©PreDestroy, utilisees respectivement 
pour la creation et la destruction d'un Bean. 

Dans le contexte de Spring, le nom de Fannotation ©PostConstruct peut induire en erreur : en 
realite une methode portant cette annotation sera appelee par Spring une fois le Bean cree et 
ses dependances injectees et non juste apres sa creation. 

Voici comment annoter une classe : 

import javax. annotation . PostConstruct; 
import javax. annotation . PreDestroy ; 



public class BusinessService { 
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©PostConstruct 
public void initO { 
// initialisation 

} 

©PreDestroy 
publ ic void cl ose( ) { 
// destruction 

} 

} 

II faut activer la detection de ces annotations, afin que Spring les prennent en compte et lance 
les methodes au moment approprie. L' activation peut se faire de deux manieres. La premiere 
consiste a declarer un BeanPostProcessor (un type de Bean specifique, capable d'agir sur un 
Bean lors du demarrage du contexte) : 

<bean class-"org.springframework. con text. annotation. 
CommonAnnotationBean Post Processor" /> 

La seconde revient a activer le support d'un ensemble d' annotations, avec la balise 
annotation-config du schema context : 

| <context:annotation-config/> 

Le Bean peut alors etre configure normalement : 

<bean id="businessService" cl ass="spl p. 1 ifecycle.BusinessService"/> 

Cette solution est un bon compromis, puisqu'elle est peu intrusive (les annotations sont consi- 
derees comme des metadonnees) et tres facile a mettre en ceuvre. En revanche, il faut bien 
activer la detection des annotations dans Spring pour qu'elle fonctionne correctement. 



Abstraction des acces aux ressources 

Les ressources (fichiers) utilisees par une application peuvent avoir de multiples supports. II 
peut s'agir de ressources disponibles sur un serveur Web via le protocole HTTP, sur le 
systeme de fichiers de la machine, dans le classpath, etc. 

Java ne propose malheureusement pas de mecanisme d' acces unique a ces ressources en 
faisant abstraction du support qu'elles utilisent. Par exemple, pour acceder a un fichier sur un 
serveur Web, nous disposons de la classe java.net. URL, mais celle-ci n'est pas utilisable pour 
les ressources accessibles depuis le classpath. 

Pour combler ce manque, Spring definit deux notions : la ressource et le chargeur de ressources. 
Comme d'habitude, ces deux notions sont materialisees sous forme d'interfaces. 

L'interface Resource represente une ressource exterieure. II en existe plusieurs implementa- 
tions, selon le type de ressource (fichier recupere depuis une URL, le systeme de fichiers, le 
classpath, etc.). L'interface ResourceLoader definit la methode getResource pour recuperer une 
ressource a partir d'un chemin, dont la syntaxe suit certaines regies. 
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L'interface Resource propose un ensemble de methodes permettant de manipuler differents 
types de ressources de facon uniforme. 

Le tableau 3-1 recapitule les methodes les plus utilisees de cette interface. 



Tableau 3-1. Principales methodes de l'interface Resource 



Methode 


Description 


exi sts 


Permet de savoir si la ressource existe, c'est-a-dire si elle a une representation « physique ». 


getlnputStream 


Ouvre un flux pour lire le contenu de la ressource. Le code appelant doit ensuite gerer la fer- 
meture de ce flux. 


getDescription 


Retourne une representation textuelle de la ressource (le nom complet du fichier, I'URL com- 
plete) pour, par exemple, afficher un message d'erreur concernant la ressource. 


getURL 


Retourne I'URL de la ressource. 


getFile 


Retourne un fichier representant la ressource. 


La recuperation d'une ressource se fait en precisant son chemin, et ce dans une syntaxe propre 
a Spring. 

Le tableau 3-2 presente des exemples de chemins pour differents types de ressources. 




Tableau 3-2. Exemples de chemins de ressources 


Prefixe 


Exemple Description 


cl asspath : 


cl asspath : /tudu/conf /dao .xml Chargement a partir du classpath 


file: 


f i 1 e : c : /data/conf . xml Chargement a partir du systeme de fichiers 


http: 


http://someserver/conf .xml Chargement a partir d'une URL 



Si une ressource est un fichier texte, son contenu peut-etre exploite de la maniere suivante : 

import java.io.BufferedReader; 
import java . io. InputStreamReader ; 
import org.springf ramework.core. io. Resource; 
(...) 

Resource resource = ... // chargement de la ressource 
BufferedReader reader = new Buff eredReader(new InputStreamReader( 

resource. getInputStream( ) 
)); 

String line = nul 1 ; 

while((line = reader. readLine( ) ) != null) { 
System. out. println( line) ; 

} 

reader. closeO; 

Linteret de 1' utilisation d'une ressource est sa parfaite independance par rapport a sa 
provenance : nous exploitons le contenu sans savoir s'il provient du systeme de fichiers ou 
d'un serveur Web. 

Voyons maintenant comment charger une ressource. 
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Acces programmatique a une ressource 

L'acces programmatique a une ressource se fait en utilisant un ResourceLoader. L'interface 
ApplicationContext heritant de ResourceLoader, un contexte d' application peut etre utilise 
pour charger des ressources. 

Voici comment charger une ressource a partir d'un contexte d' application : 



La ressource est recuperee a partir du classpath. Comme pour Fintemationalisation, il est 
preferable de ne pas utiliser directement le contexte d' application pour recuperer des ressour- 
ces, mais plutot de passer par l'interface ResourceLoader. Un Bean necessitant d'acceder a des 
ressources peut implementer l'interface ResourceLoaderAware. II se verra alors injecter un 
ResourceLoader juste apres F initialisation de ses proprietes. 

Le service metier suivant implemente ResourceLoaderAware pour recuperer un fichier depuis le 
classpath a partir du chargeur de ressources injecte : 

import org. springf ramewor k. context. ResourceLoaderAware; 
import org. sp ringf ramewor k. co re. io. Resource; 
import org. springf ramewor k. core. io. Resource Loader; 

public class BusinessService implements ResourceLoaderAware { 
private ResourceLoader resourceLoader; 

public void setResourceLoader(ResourceLoader resourceLoader) { 
this. resourceLoader = resourceLoader; 

} 

public void initO { 

Resource resource = resourceLoader. getResource( 
"cl asspath: /spl p/resource/wel come. txt" 

); 

// exploitation de la ressource 
(...) 



Le Bean est configure de la maniere suivante, en precisant une methode d' initialisation : 

<bean id="businessService" class-" spl p. resource. BusinessService" 
init-method="init"/> 



Resource resource = context. getResource( 
"cl asspath : /spl p/resource/someText . txt 



Injection de ressources 



Spring utilise de maniere intensive la notion de ressources. En effet, de nombreuses classes 
internes a Spring possedent des proprietes de type Resource. Cela permet de gerer de facon 
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uniforme et smtout efficace toutes les ressources externes, car Spring permet de faire facile- 
ment l'injection de ressources, via un PropertyEditor dedie aux ressources. 

Prenons le Bean suivant, qui dispose d'une propriete de type Resource : 

import org. spr i ngf ramework. core. io. Resource; 

public class BusinessServiceResourcelnjected { 

private Resource resource; 

public void setResource( Resource resource) { 
this. resource = resource; 

} 

(...) 

} 

II est possible d'injecter une Resource en precisant simplement son chemin dans Fattribut 
val ue de la balise bean, Spring se chargeant alors de la conversion : 

<bean id="businessService" cl ass-" spl p. resource. Bus inessService"> 
<property name="resource" 

value="classpath:/splp/resource/welcome.txt " /> 
</bean> 



Spring dans une application Web 

Spring est le plus souvent utilise dans le cadre d'une application Web, oil il permet de definir, 
par exemple, les parties metier et persistance. II peut aussi s'integrer avec un framework de 
presentation autre que Spring MVC (Struts, JSF, GWT, etc.). Ces frameworks proposent gene- 
ralement un support facilitant Finterfacage avec Spring. 

Le chargement du contexte Spring dans une application Web peut etre pris en charge par des 
mecanismes fournis nativement. Spring propose ensuite une API pour recuperer les Beans, par 
exemple, a partir des servlets de F application. Le chargement du contexte Spring passe par la 
declaration d'un ecouteur de contexte de servlet, qui doit etre declare dans le fichier web.xml 
de F application : 

<web-app (...)> 

<context-param> 
<pa ram- name>contextConf i g Location </pa ram- name><— © 
<param-val ue>/WEB- INF/appl i cation- context .xml </param-val ue><— Q 

</context-param> 

<1 i stener> 

<1 i stener-cl ass> 

org. spr i ngf ramework. web. context .Context Loader Li stener<— Q 

</l i stener-cl ass> 
</l istener> 
(...) 

</web-app> 
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Le parametre contextConfig Location (Q) precise la localisation du fichier de configura- 
tion (Q). Un seul fichier figure dans l'exemple, mais il est possible de preciser une liste de 
fichiers, separes par des virgules. II est aussi possible d'utiliser la syntaxe de l'abstraction 
d'acces aux ressources de Spring pour preciser le chemin des fichiers. La classe d'ecouteur 
utilisee est ContextLoaderListener (©), fournie par Spring. 

Dans une application Spring MVC ou avec un framework Web integrant Spring, la recupe- 
ration des Beans se fait generalement avec de l'injection de dependances. Le besoin typi- 
que est l'injection de services metier dans les controleurs de 1' application. Generalement, 
les controleurs sont aussi des Beans Spring. L'injection de dependances est des lors tres 
aisee. 

Si les controleurs de F application ne sont pas geres par Spring, par exemple dans le cas de 
controleurs sous forme de servlets, il est possible de recuperer le contexte Spring avec un 
appel statique : 

WebApplicationContext ctx = WebApplicationContextUtils.** 

getWebAppl i cati onContext ( servl etContext ) ; 

L'acces au contexte permet ensuite de recuperer les Beans Spring. II s'agit d'une recupe- 
ration active (l'equivalent d'un look-up JNDI), ce qui ne suit pas le principe d'injection de 
dependances. Cependant, c'est le prix a payer quand les controleurs ne sont pas geres par 
Spring. 

Le contexte que nous venons de definir est le contexte dit de 1' application Web. II peut 
avoir un ensemble de contextes his correspondant chacun a des modules d'une application 
Web. 

La notion de hierarchie de contextes met en jeu des regies de visibilite entre Beans (seuls les 
Beans des contextes parents sont visibles aux contextes fils, pas l'inverse). Cette notion sera 
abordee plus en detail au chapitre 7, qui traite de Spring MVC. 



Externalisation de la configuration 

II n'est pas rare que des Beans necessitent des parametres de configuration qui changent selon 
les environnements (comme des parametres de connexion a une base de donnees, un chemin 
sur le systeme de fichiers, l'adresse d'un serveur SMTP, etc.). 

II est utile de pouvoir regrouper ces parametres, generalement dissemines a travers des defini- 
tions de Beans, dans un meme fichier de proprietes, beaucoup plus concis et court qu'un 
fichier XML. Cela permet aussi de reutiliser les fichiers de configuration XML d'un environ- 
nement a un autre, en changeant seulement le fichier de proprietes. 

Prenons l'exemple de la configuration d'une connexion a une base de donnees (via une 
DataSource). Voici le fichier de configuration config.properties : 

database. dri ver=org. hsql db. jdbcDri ver 
database.url=jdbc: hsql db : mem :tudu- test 
database. user=sa 
database. password- 
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Voici la configuration XML correspondante : 

<bean cl as s="org.springframework. beans. factory .config. 
Property PI acehol derConf igurer"> 
<property name="location" val ue=" config. properties " /> 
</bean> 

<bean id="dataSource" cl ass="org.springf ramewor k.jdbc.dat asource. 
Singl eConnectionDataSource"> 

<property name="driverClassName" val ue=" ${database. driver} " /> 

<property name="url" val ue=" ${database. url } " /> 

<property name="username" value="${database.user} " /> 

<property name="password" value="${database. password} " /> 
</bean> 

Nous configurons un PropertyPl acehol derConfigurer, qui est un post-processeur de fabrique. 
II va utiliser le fichier config.properties pour modifier les proprietes des Beans du contexte. 
II est maintenant possible d' utiliser la syntaxe $ { nomPropri ete} dans le fichier XML pour faire 
reference aux proprietes du fichier. C'est ce que nous faisons pour la definition de la 
DataSource. 

II est aussi possible de positionner un PropertyPl acehol derConfigurer avec la balise 
property-placeholder du schema context : 

<context: property -placeholder location-" config. properties" /> 

Dans les deux modes de configuration, la propriete 1 ocati on peut utiliser la syntaxe d'abstrac- 
tion des ressources et done faire reference a un fichier via une URL, le systeme de fichiers, le 
classpath, etc. 

Enfin, une fonctionnalite interessante du PropertyPl acehol derConfigurer est de reconnaitre, 
dans le fichier de configuration, les proprietes systeme et les proprietes deja definies : 

# propriete systeme 

da ta. root. dir=${ user. dir} /data 

# reference a la propriete precedente 
data .tudu.di r=${data . root.di r}/tudu 



Langage d'expression 

Spring 3.0 a introduit la possibilite d'utiliser un langage d'expression, ou EL (Expression 
Language), pour la definition des Beans, que ce soit dans la configuration XML ou dans celle 
par annotation. Lutilisation d'un langage d'expression permet de rendre la definition des 
Beans plus dynamiques, car il est alors possible de faire reference a des proprietes systeme ou 
a d'autres Beans du contexte lors de la configuration d'un Bean. 

Le langage d'expression utilise dans Spring est tres proche dans sa syntaxe de langages tels que 
Java Unified EL ou OGNL. Pour la configuration XML, il est possible d'utiliser le langage 
d'expression pour tout attribut, l'expression etant alors evaluee au chargement du contexte. 
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Voici un exemple d' utilisation du langage d' expression pour qu'un Bean se configure a partir 
d'un autre Bean : 

<bean id="userl" cl ass="tudu. domain. model .User"><— Q 

<property name-"login" value="acogoluegnes" /> 

<property name="fi rstName" val ue="Arnaud" /> 

<property name="lastName" val ue="Cogol uegnes" /> 
</bean> 

<bean id-"user2" class-'tudu. domain. model .llser"><—@ 

<property name="login" val ue="#{userl . login}" /> 

<property name="fi rstName" val ue="#{userl . fi rstName} " /> 

<property name="lastName" val ue="#{userl . 1 astName} " /> 
</bean> 

Un premier Bean est defini de facon classique au repere Q ; ses proprietes sont assignees 
directement. Le second Bean (Q) utilise les proprietes du premier pour sa configuration. En 
effet, les attributs val ue des balises property utilisent le langage d'expression, car leur valeur est 
de la forme #{...}, ce qui correspond a une expression. Ces expressions font reference au premier 
Bean, userl, et a ses proprietes, via la syntaxe classique d'acces aux proprietes d'un JavaBean. 

Chaque expression est evaluee au sein d'un contexte, et Spring positionne dans ce contexte un 
ensemble de variables dites implicites. II est possible de faire reference a ces variables impli- 
cites dans toute expression. 

La variable systemProperties permet, par exemple, d'acceder aux proprietes systeme : 

<bean id="dataSource" class="org.springframework. jdbc.datasource.^ 
Singl eConnecti onDat a Source" > 
<property name="dri verCl ass Name" 

val ue="#{ systemProperties .databaseDri ver} " /> 

<property name="url" val ue="#{ systemProperties .databaseLIrl } " /> 

<property name="username" 

val ue="#{ systemProperties .databaseUser}" /> 

<property name="password" 

value="#{systemProperties .databasePassword} " /> 
</bean> 

Les proprietes systeme peuvent etre positionnees de fa§on programmatique : 

System. set Property ( "databaseDri ver" , "org. hsql db. jdbcDri ver" ) ; 
System, set Property ( "databaseLIrl " , " jdbc: hsql db:mem: tudu-el " ) ; 
System. set Property ( "databaseUser" , "sa" ) ; 
System. set Property ( "databasePassword" , "" ) ; 

Mais aussi lors du lancement d'un processus Java : 

java -Dda tabaseDriver=org. hsql db. jdbcDri ver 

- Ddat aba sell rl=jdbc: hsql db: mem: tudu-el -D=databaseUser-sa 
-DdatabasePassword= splp.MainCl ass 
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Le cote facilement parametrable des proprietes systeme est particulierement utile, combine a 
revaluation dynamique des expressions. 

L'utilisation d'expressions n'est pas limitee a la configuration XML, l'annotation ©Value, 
appliquee sur des proprietes, acceptant aussi les expressions : 

import org. spring-framework, beans, factory .annotation. Value; 

public class User { 

@Val ue( "#{systemProperties .todouser Login} " ) 
private String login; 

@Val ue( "#{systemProperties . todouser Fi rstName} " ) 
private String firstName; 

@Val ue( "#{systemProperties . todouser Last Name } " ) 
private String lastName; 

(...) 

} 

Le Bean peut alors etre declare via XML, en activant bien le support pour les annotations : 

<bean id-"userl" class="tudu. domain. model .User" /> 
<context:annotation-config /> 

Les expressions sont aussi utilisables avec une configuration 100 % annotation, c'est-a-dire 
que le Bean est automatiquement decouvert par Spring, grace a F apposition d'une annotation 
de type ©Component sur sa classe. 



Publication d'evenements 

Le modele de communication le plus courant entre composants est le modele direct, dans 
lequel le composant emetteur communique directement avec le composant destinataire. Ce 
modele est simple et adapte a la plupart des situations. Cependant, il impose un fort couplage 
entre F emetteur et le destinataire (appele aussi le « consommateur »), meme si un raisonne- 
ment par interface permet un premier niveau de decouplage, en ne liant pas F emetteur a 
F implementation du consommateur. 

La situation se complique si Femetteur veut communiquer avec plusieurs composants. II peut 
alors les appeler successivement, mais il s'agit la d'une solution rigide et peu extensible. II est 
preferable d'utiliser une communication evenementielle, c'est-a-dire que Femetteur publie un 
message qui est communique a des objets ecouteurs. L'emetteur n'a pas connaissance de ces 
objets et se contente de publier ses messages. On obtient alors un tres bon decouplage entre 
les objets emetteurs et destinataires et surtout une solution fortement extensible. Cette exten- 
sibilite peut passer par l'ajout de nouveaux ecouteurs, mais aussi par la variete des types de 
messages publies. 



Concepts avarices du conteneur Spring I 

Chapitre 3 | 

Le contexte d' application de Spring propose un tel modele de communication evenementiel. 
Nous allons voir comment un Bean peut ecouter les evenements publies au sein d'un contexte 
Spring puis comment publier ses propres evenements. 

Ecouter des evenements 

Pour etre notifie des evenements publies au sein d'un contexte Spring, un Bean doit imple- 
menter Finterface Appl i cati onLi stener : 

import org. springframework. context. Appl i cati on Event; 
import org. springframework. context. Appl i cati on Li stener; 

public class UnObservateur implements ApplicationListener { 

public void onApplicationEventtApplicationEvent event) { 
// gestion de 1 'evenement 
(...) 

} 

} 

Cette interface definit une seule methode, onApplicationEvent, qui accepte un Appl i cati on Event 
en parametre. Appl i cati on Event est une classe de base, que Ton peut specialiser selon le besoin. 

Un contexte d' application publie automatiquement des evenements qui heritent de 
ApplicationEvent. 

Le tableau 3-3 recapitule certains de ces evenements. 



Tableau 3-3. Evenements publies par un contexte Spring 



Evenement 


Description 


Con text Refreshed Event 


Publie quand le contexte est initialise ou rafraTchi (appel de la methode refresh). 
Cet evenement peut etre publie plusieurs fois pendant le cycle de vie d'un contexte. 


ContextStartedEvent 


Publie quand le contexte est demarre. Cet evenement peut etre publie apres un arret 
explicite du contexte. Des Beans peuvent aussi recevoir ce signal quand ils sont ini- 
tialises de maniere tardive. 


Context Stopped Event 


Publie quand le contexte est arrete, avec la methode stop. Un contexte arrete peut 
etre redemarre. 


ContextCl osedEvent 


Publie quand le contexte est ferme. Un contexte ferme arrive en fin de vie et ne peut 
plus etre rafraTchi ou redemarre. 



Ces evenements sont generalement utilises par des Beans fortement lies au contexte. Un Bean 
applicatif peut les utiliser pour journaliser le cycle de vie du contexte, a Litre informatif. Un 
Bean interesse par un certain type d'evenement doit effectuer une verification sur la classe de 
l'evenement qui lui esL passee eL effecLuer un LransLypage le cas echeant : 

import org. springframework. context. Appl i cati on Event; 
import org. springframework. context. Appl i cati on Li stener; 
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import org.springf ramework. con text. event. Context Refreshed Event ; 

public class UnObservateur implements Appl icationListener { 

public void onApplicationEvent(ApplicationEvent event) { 
if(event instanceof ContextRef reshedEvent) { 
ContextRef reshedEvent refreshEvent = 
(ContextRef reshedEvent) event; 

(...) 

} 

} 



Publier des evenements 

Une application peut etre amenee a publier ses propres evenements, afin de profiter du decou- 
plage qu'offre le modele evenementiel. Cela se fait en deux temps : il faut d'abord definir la 
classe de l'evenement puis rendre le Bean emetteur capable de publier des evenements. 

Supposons que nous souhaitions publier un evenement quand un utilisateur est cree dans Tudu 
Lists. Un consommateur de cet evenement pourrait, par exemple, etre un Bean charge 
d'envoyer une notification par e-mail a un administrateur. 

Pour cela, nous definissons un UserCreatedEvent qui herite de Appl icationEvent : 

import org.springf ramework. context. Appl icationEvent; 
import tudu. domain. model .User; 

public class UserCreatedEvent extends Appl icationEvent { 
private User user; 

public UserCreatedEventtObject source, User userCreated) { 
super(source) ;<— O 
this. user = userCreated;<— Q 

) 

public User getUserO {<— Q 
return user; 

} 

} 

Un Appl icationEvent doit etre cree en lui passant la source de l'evenement, c'est-a-dire Fobjet 
emetteur (0). Nous passons egalement Futilisateur fraichement cree et le stockons dans l'evene- 
ment (Q). Un accesseur est defini afin que les consommateurs puissent y acceder (©). 

Dans notre exemple, l'objet emetteur est le UserManager de Tudu Lists. II doit publier un 
evenement lors de l'execution de la methode createUser et doit avoir pour cela acces a un 
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Bean du contexte Spring permettant de publier des messages, un Appl i cation - 
EventPubl i sher. 

Le contexte Spring etant un Appl icationEventPubl isher, il est possible de publier des evene- 
ments en implementant Finterface Appl icationContextAware et en utilisant le contexte. 
Cependant, il est preferable de limiter l'acces au contexte et done d'implementer seulement 
l'interface Appl icationEventPubl isherAware : 

import org. springframework. context .Appl i cat ion EventPubl isher; 

import org. springframework. context .Appl i cat ion EventPubl i sher Aware; 

import tudu. domain. model .User; 

import tudu. service. UserAl readyExistsException; 

import tudu. service. Use rManager; 

public class UserManagerlmpl implements 

Use rManager, Appl i cat ion Event Publ i sher Aware { 

pri vate Appl icationEventPubl i sher appl i cat i on Event Publ i sher ;<— Q 

public void createUser(User user) 

throws UserAl readyExistsException { 
(...) 

UserCreatedEvent event = new UserCreatedEvent(thi s .user) ;<— Q 
appl icationEventPubl is her. publ ishEvent( event) ;<— Q 

} 

public void setApplicationEventPublisher(<— Q 

Appl i cationEventPubl isher applicationEventPublisher) { 
this.applicationEventPublisher = applicationEventPublisher; 

} 

(...) 

} 

L'interface Appl icationEventPubl isherAware definit un accesseur pour avoir acces a l'emet- 
teur d'evenements (Q). Nous le stockons done dans une propriete (©). Suite a la creation 
d'un utilisateur, l'evenement est cree (Q) puis publie (©). 



Quand utiliser le modele evenementiel de Spring ? 

Le modele evenementiel fourni dans Spring a Favantage d'etre facilement exploitable. II est 
cependant limite techniquement et ne doit etre utilise que pour les cas simples. 

Voici les limitations de ce modele evenementiel : 

• II est par defaut synchrone. Un ecouteur peut done bloquer l'execution du thread courant si 
son traitement est long. On peut cependant modifier ce comportement en parametrant 
l'Appl icationEventMulti caster du contexte (par defaut un SimpleAppl icationEventMulti - 
caster). Cependant, si les traitements des ecouteurs sont appeles dans des threads differents 
de celui de l'emetteur, ils ne pourront pas s'inserer dans son contexte transactionnel. 
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• II n'est pas transactionnel. Si un evenement est publie puis qu'une erreur survient apres les 
traitements des ecouteurs, ceux-ci ne pourront etre annules. II n'existe pas de moyen de 
rappel d'un message publie. En revanche, ces traitements, s'ils sont executes dans le meme 
thread, peuvent participer a la meme transaction que celle de Femetteur. Cela signifie que si 
les traitements des ecouteurs ne sont que des operations de base de donnees, ils seront eux 
aussi transactionnels. 

Le modele evenementiel de Spring ne doit done pas etre utilise pour des mecanismes critiques 
s'il les rend non transactionnels. II ne doit pas non plus etre utilise si les traitements des ecouteurs 
sont longs et peuvent bloquer le deroulement de Fobjet emetteur. 

Pour ce genre de problematiques, une solution telle que JMS est plus adaptee, car elle est 
multithreadee et transactionnelle (sous-reserve d'utiliser un gestionnaire de transactions JTA, 
comme les implementations Open Source Atomikos ou Bitronix Transaction Manager). 



Scinder les fichiers de configuration 

Un contexte d' application Spring peut etre charge a partir de plusieurs fichiers. Cela se revele 
particulierement utile pour un ensemble de raisons, notamment les suivantes : 

• Taille des fichiers : pour des applications de grande taille, les fichiers peuvent devenir rapi- 
dement tres gros et difficilement maintenables. 

• Reutilisation : un meme fichier peut etre utilise pour differents environnements (tests 
unitaires, preproduction, production, etc.). 

Le decoupage se fait generalement techniquement, e'est-a-dire que les couches de 1' applica- 
tion (DAO, services, controleurs) auront chacune leur fichier de configuration. II est aussi 
possible d'effectuer un decoupage fonctionnel (un fichier d'une couche technique par module 
fonctionnel) si 1' application comporte un grand nombre de Beans. 

Si le decoupage par couche est relativement evident, il est generalement preferable de mettre 
des reglages fortement changeants dans un fichier dedie. Dans Tudu Lists Core, les DAO 
doivent etre definis dans au moins un fichier. L application fournit la partie la plus complexe 
dans le fichier /src/main/resources/core/tudu/conf/jpa-dao-context.xml. 

Ce fichier contient la declaration des DAO et la structure de la configuration JPA : 

<bean id-"entityManagerFactory" 

cl ass="org .springf ramework.orm. jpa . 

Loca 1 Conta i ne r Entity Manager Factory Bean" > 
<property name="dataSource" ref="dataSource" /> 
<property name=" jpaVendorAdapter" ref=" jpaVendorAdapter" /> 
<property name="persistenceXml Location" 

val ue="cl asspath: /tudu/conf /persi stence.xml "/> 
<property name=" jpaProperti es" ref="jpaProperties" /> 
</bean> 

<bean id-"userDAO" class-"tudu.domain.dao. jpa.UserDAOJpa"/> 
(...) 
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Trois Beans ne sont pas definis dans ce fichier, car ils sont susceptibles de changer selon 
l'environnement : 

• dataSource : il s'agit de la connexion a la base de donnees. Elle peut varier fortement d'un 
environnement a 1' autre (ex. : pool de connexions embarque dans F application ou defini par 
le serveur d' applications). 

• jpaVendorAdapter : definit 1' implementation JPA utilisee (Hibernate, TopLink, etc.). 

• j pa Properties : definit des proprietes pour F implementation JPA (comme Futilisation d'un 
cache). 

Le fichier jpa-dao-context.xml contient les elements necessitant une connaissance poussee 
de Tudu Lists. II laisse la possibilite de parameter les elements les plus courants dans un ou 
plusieurs autes fichiers via ces trois Beans. 

Un fichier de configuration utilise pour les tests unitaires sur la couche de DAO complete ce 
fichier avec la definition (notamment) des trois Beans manquants : 

<bean id="dataSource" 

cl ass-" org. springf ramework. jdbc .datasource. 
Singl eConnectionDataSource"> 
<property name="dri verCl assName" value="org.hsqldb. jdbcDriver" /> 
<property name="url" value="jdbc:hsqldb:mem:tudu-test" /> 
<property name="username" value="sa" /> 
<property name="password" value="" /> 
<property name="suppressCl ose" value="true" /> 
</bean> 

<bean id="jpaVendorAdapter" 

cl as s-" org. springf ramework. orm.j pa . vendor 
Hi bernateJpa Vendor Ada pter"> 
<property name="showSql " val ue="fal se" /> 
<property name="generateDdl " val ue="true" /> 
<property name="database" val ue="HSQL" /> 
</bean> 

<util properties id="jpaProperties"> 

<prop key=" hi be mate, cache. provider_cl ass "> 
o rg. hibernate. cache. NoCache Provider 
</prop> 

<prop key=" hibernate. cache. use_query_cache" >f a 1 se</prop> 
<prop key=" hibernate. cache. use_second_l evel_cache">fal se</prop> 
</util :properties> 

On peut aussi mettre dans un fichier dedie la configuration des problematiques transver- 
ses, implementees generalement avec de la programmation orientee aspect. L'exemple 
typique est la gestion des transactions, qu'il vaut mieux isoler de la declaration des services 
metier. 
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Enfin, la scission des fichiers peut etre combinee avec l'externalisation de la configuration, via 
un PropertyPlaceholderConfigurer, qui pemiet de placer des parametres dans des fichiers de 
proprietes. 

Les implementations d'ApplicationContext acceptent un tableau de chaines de caracteres, 
permettant de preciser les differents fichiers de configuration : 

Appl icationContext context = new FileSystemXmlApplicationContextt 
new String[] { " context -dao.xml " , "con text -servi ce.xml " } 

>: 

II est aussi possible d'utiliser la balise import du schema beans. Cette balise permet d'inclure 
des fichiers de configuration, en utilisant la syntaxe de l'abstraction des ressources de Spring : 

<import resource-" cl as spat h : It udu/conf /j pa- dao- context .xml "/> 

<import resource="cl a sspath: It udu/conf /servi ce- con text. xml "/> 

<import resource="cl a sspath : It udu/conf /trans act ion -context. xml "/> 

<import resource-" cl asspath:/t udu/conf /security -context .xml "/> 

Les fichiers de configuration peuvent aussi etre precises avec des caracteres de remplacement 
{wildcards) repondant a la syntaxe Ant. 

Lexemple precedent pourrait aussi s'ecrire de la facon suivante : 
<import resource-" classpath:tudu/conf/*-context. xml " /> 

Spring utilise en ce cas tous les fichiers du classpath dont le nom se termine par -context. 
L utilisation de caracteres de remplacement se decline aussi pour la creation d'un 
ApplicationContext : 

Appl icationContext context = new ClassPathXmlApplicationContext( 
new String[]{" classpath:tudu/conf/*-context.xml "} 

>; 

Spring reconnait aussi les caracteres ** pour effectuer une recherche recursive dans les reper- 
toires du classpath. 

L utilisation de caracteres de remplacement apporte une extensibilite interessante : le charge- 
ment du contexte peut etre defini avec une expression Ant definissant une convention de loca- 
lisation des fichiers de configuration Spring. Ajouter un JAR contenant un fichier de contexte 
Spring suivant cette convention fera que ce contexte sera charge automatiquement et viendra 
enrichir le contexte de 1' application. En combinant ces caracteres de remplacement avec les 
possibilites d'autowiring du conteneur (sur les collaborateurs ou sur les collections), il est 
possible d'obtenir tres facilement un systeme de plug-ins. 

Spring permet de scinder ses fichiers de contexte. Le fait de les organiser correctement favo- 
rise la souplesse de la configuration d'une application. Cela permet de reutiliser au maximum 
les fichiers de configuration complexes dans dilferents environnements. La scission pemiet 
aussi de mettre en evidence les problemes de conception, car une application mal concue est 
generalement difficile a configurer. 
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Langages dynamiques 

Spring propose un support pour les langages dynamiques, appeles aussi langages de script. II 
est done possible de definir des Beans Spring sous la forme de scripts, dans un langage diffe- 
rent que Java. Spring gere la compilation de ces scripts avec le compilateur adapte. 

Pour chaque langage dynamique, il faut bien evidemment qu'un interpreteur ecrit en Java soit 
disponible. L' interpreteur doit etre fourni sous la forme d'un fichier JAR et ajoute au class- 
path de F application. 

Spring propose un support natif pour les langages dynamiques suivants : 

• beanShell (http://www.beanshell.org/), un langage de script tres proche de Java. Le code 
source beanShell peut d'ailleurs contenir du Java, tout en laissant la possibilite d'utiliser 
des fonctionnalites propres a tout langage de script (par exemple, les variables n'ont pas 
l'obligation d'etre typees). 

• Groovy (http://groovy.codehaus.org/), un langage dynamique fortement integre a la plate- 
forme Java. Son code source peut etre compile en bytecode Java ou interprete dynamique- 
ment. Groovy inclut des concepts de programmation tels que les closures, tout en acceptant 
du code Java dans ses scripts. 

• JRuby (http://jruby.codehaus.org/), une implementation Java du langage Ruby. JRuby permet 
d'executer des scripts Ruby, mais aussi d'inclure du code Java. JRuby permet de combiner 
la puissance de Ruby et la robustesse de la machine virtuelle Java pour F execution. 

Pour que F interaction entre Spring et les langages dynamiques se fasse correctement, il est 
obligatoire d'etablir un contrat entre les deux mondes, sous la forme d'une interface. Nous 
allons done definir une interface tres simple, qui va nous permettre d'illustrer F utilisation des 
langages dynamiques. 

Cette interface correspond a F operation d' addition : 
package splp. scripts; 
public interface Adder { 

public int add(int x.int y); 

} 

Spring fournit un schema XML pour configurer les Beans des langages dynamiques. Ce schema 
s'appelle 1 ang, et voici sa declaration : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xml ns :xsi-"http: //www. w3.org/2001/XMLSchema -instance" 
xmlns:lang=" http://www.spr ingframework.org/schema/lang" 
xsi :s enema Locati on="http: //www. springframework.org/schema/beans 
http: //www. springf ramework.org/schema/beans/spring-beans .xsd 
http: //www. spri ngframework.org/ schema /I ang 
http://www.springframework.org/schema/! ang/spring-lang.xsd"> 

</beans> 
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Nous allons maintenant voir comment deflnir des Beans sous la forme de scripts dedies, mais 
aussi directement dans le fichier XML de Spring. Nous effectuerons aussi de F injection de 
dependances entre Beans Java et Beans dynamiques. Nous verrons ensuite comment les 
Beans fondes sur les langages de scripts peuvent etre modifies dynamiquement. Nous termi- 
nerons sur des considerations concernant Futilisation de ces langages. 

Declaration de Beans dans des fichiers dedies 

Nous allons deflnir une implementation de Adder dans chacun des langages de scripts suppor- 
tes par Spring. 

Commencons par Groovy, qui est le plus proche de Java : 
import splp. scripts. Adder; 

class GroovyAdder implements Adder { 

public int addd'nt x.int y) { x + y } 

} 

La syntaxe est tres proche de celle de Java, et seule 1' implementation de la methode differe 
(pas de mot-cle return et pas de point-virgule de fin d'instruction). 

La declaration de cette implementation Groovy se fait de la maniere suivante : 

<lang:groovy id="groovyAdder" 
script-source="cl as spath:/splp/scripts/Adder. groovy" /> 

La balise groovy du schema lang permet de deflnir un Bean sous forme de script Groovy. 
Le script est localise avec l'attribut script-source. II peut se trouver aussi bien dans le class- 
path que sur le systeme de fichiers. 

Groovy supportant l'import et 1' implementation de classe Java, le Bean peut etre utilise 
comme un Bean Java, sans fournir d' information supplemental : 

Adder groovyAdder = (Adder) context. getBean( "groovyAdder" ) ; 
Assert. assertEqual s(7 , groovyAdder. add(3, 4)); // assertion JUnit 

L implementation beanShell de notre Bean est beaucoup plus simple : 

int addd'nt x.int y) { 
return x+y; 

} 

En effet, beanShell n'etant pas a proprement parler un langage oriente objet, la declaration du 
Bean doit contenir 1' interface implementee : 

<lang:bsh id="bshAdder" 

script-source="cl asspath : /spl p/scri pts / Adder .bsh" 
script-interfaces="splp. scripts. Adder " /> 
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L'attribut script -interfaces contient la oil les interfaces (separees par des virgules) que le 
Bean est cense implemented Preciser cela permet d'utiliser le Bean comme un Bean Java : 

Adder bshAdder = (Adder) context. getBeanC'bshAdder") ; 
| Assert. assertEquals(7, bshAdder. add(3, 4)); // assert JUnit 

Enfin, voyons 1' implementation JRuby de notre Bean : 

class RubyAdder 

def add(x.y) 
x+y 

end 

end 

La configuration XML est la suivante : 

<lang:jruby id="rubyAdder" 

script-source="cl asspath : /spl p/scri pts /Adder . rb" 
script-interfaces="splp. scripts. Adder " /> 

Comme pour le beanShell, il est necessaire de preciser 1' interface implementee par le Bean. 
L'utilisation reste la meme que pour un Bean Java : 

Adder rubyAdder = (Adder) context. getBeanC'rubyAdder"); 
Assert. assertEquals(7, rubyAdder. add(3, 4)); 

Rafraichissement des Beans 

Quand un Bean est defini a partir d'un script qui se trouve sur le systeme de fichiers, Spring 
est capable de prendre en compte toute modification du script. Cette fonctionnalite est certai- 
nement la plus interessante dans le support des langages dynamiques. En effet, le rafraichisse- 
ment des Beans permet de changer le comportement d'une application sans necessiter son 
rechargement ou son redeploiement. 

Chacune des balises d'utilisation des langages de scripts propose un attribut refresh-check- 
del ay qui permet de preciser, en millisecondes, une periode de rafraichissement : 

<lang:groovy id="groovyAdder" 

s cript- sour ce="cl asspath: /spl p/scri pts /Adder . groovy" 
ref reshcheck-del ay="5000" /> 

Quand une methode est appelee sur le Bean, Spring verifie si la periode de rafraichissement 
s'est ecoulee et recompile le script du Bean si necessaire. Par defaut, cette fonctionnalite est 
desactivee. Elle ne fonctionne pas pour les Beans definis en ligne (directement dans le 
contexte Spring). 
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Declaration de Beans en ligne 

Spring permet la definition de Beans directement dans le fichier de configuration du contexte. 
Cette methode constitue une bonne solution de rechange pour les scripts simples et ne neces- 
sitant pas de rafraichissement. 

Pour chacun des langages dynamiques supportes, une balise inline-script est disponible. 
C'est dans cette balise que peut etre defini le script. 

Reprenons l'exemple qui consiste a implementer une addition. Voici la definition en ligne 
avec Groovy : 

<lang:groovy id="groovyAdder"> 
<lang:inline-scn'pt> 
import splp. scripts. Adder; 
class GroovyAdder implements Adder { 
public int addd'nt x.int y) { x + y } 

} 

</l ang:inline-script> 
</lang:groovy> 

Voici une definition en ligne avec beanShell : 

<lang:bsh id="bshAdder" 

script- interfaces="spl p. scri pts . Adder "> 
<lang:inline-script> 
int addd'nt x.int y) { 

return x+y; 

} 

</l ang:inline-script> 
1 </lang:bsh> 

Et voici la definition en ligne en JRuby : 

<lang:jruby id-"rubyAdder" 

script-interfaces="spl p. scri pts. Adder "> 
<lang:inline-script> 
class RubyAdder 
def add(x.y) 

x+y 
end 
end 

</lang:inline-script> 
</l ang: jruby> 



Injection de dependances 

Tout Bean defini dans un langage dynamique peut se voir injecter des donnees (simples ou des 
collaborateurs) avec la balise 1 ang: property. Cette balise a la meme semantique que 
beans : property. 
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Nous pouvons reprendre notre exemple de Bean effectuant des additions (nous allons privile- 
gier Groovy pour cet exemple). Le Bean Groovy peut deleguer l'operation a un autre Bean, 
implementant aussi l'interface Adder : 

import splp. scripts. Adder; 
class GroovyAdder implements Adder { 
Adder adder; 

public int addO'nt x.int y) { adder. add(x.y) } 

} 

Notons qu'aucun modificateur pour la propriete adder n'est defini explicitement dans le Bean 
Groovy. En effet, en Groovy, les modificateurs et les accesseurs sont generes automatiquement. 

Voyons maintenant une implementation Java de Adder qui va etre utilisee dans le Bean 
Groovy : 

public class Adderlmpl implements Adder { 
public int add(int x, int y) { 
return x+y; 

1 

} 

II est possible d'injecter cette implementation Java dans le Bean Groovy via Spring : 
<bean id-"javaAdder" class-"splp. scripts. Adderlmpl " /> 

<lang: groovy id="groovyAdder" 

s cr ipt- source-" cl a sspath:/splp/scripts/l_azyAdder. groovy "> 

<lang:property name="adder" ref=" javaAdder" /> 
</lang:groovy> 

Ce mode de fonctionnement n'a pas de reel interet (une addition en Groovy est aussi rapide 
qu'en Java), mais il a le merite de nous montrer la possibilite d'injecter un Bean Java dans un 
Bean Groovy. 

L'operation inverse, c'est-a-dire l'injection dans un Bean Java d'un Bean defini dans un 
langage dynamique, est possible. Prenons la classe Java suivante, definissant un ensemble 
d'operations et deleguant l'addition a un Adder : 

public class Powerful Cal cul ator { 

private Adder adder; 

public int add(int x.int y) { 
return adder. add(x, y) ; 

1 
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(...) 

public void setAdder( Adder adder) { 
this .adder = adder; 

} 

} 

Nous pouvons declarer les deux Beans et effectuer l'injection du Adder Groovy dans le 
calculateur Java : 

<lang:groovy id="groovyAdder" 

script-source="cl asspath : /spl p/scripts/ Adder .groovy" /> 

<bean id="cal cul a tor" cl ass="spl p. scripts . Powerful Cal cul ator"> 
<property name="adder" ref-"groovyAdder" /> 

</bean> 

Les injections que nous avons vues sont rendues possibles grace a l'etablissement d'un contrat 
entre les Beans. Utiliser une interface facilite done fortement la collaboration entre Beans de 
nature differente. 



Considerations sur les langages dynamiques 

Deux raisons principales peuvent justifier F utilisation de Beans fondes sur des langages dyna- 
miques dans une application Spring. La premiere est la capacite inherente des langages de 
scripts a faciliter certaines taches de programmation. 

Groovy dispose, par exemple, d'un tres bon support pour XML, beaucoup plus simple et 
productif que celui de Java. La deuxieme raison est la possibilite de rafraichir les Beans 
fondes sur des langages dynamiques. II s'agit la d'une grande plus-value dans les applications 
Java, qui ne peuvent etre modifiees sans redemarrage ou redeploiement. 

Les langages dynamiques peuvent done etre utilises pour definir des Beans mis en ceuvre dans 
des parties paiticulierement mouvantes d'une application (validation, regies de calcul, etc.). 
lis peuvent aussi etre utilises pour proposer des interfaces d' administration, par exemple sous 
la forme d'une pseudo-ligne de commandes. II faut cependant etre extremement prudent avec 
ce genre de fonctionnalites, principalement a cause de la puissance des langages dynamiques 
et done des problemes de securite qui en decoulent. 

Les langages dynamiques doivent en revanche etre evites pour les taches oil la rapidite et la 
tenue a la charge sont primordiales, car ils sont plus lents, voire beaucoup plus lents que du 
Java natif. Enfin, leur utilisation doit faire l'objet de la meme rigueur qu'en Java, et ce malgre 
leurs possibilites syntaxiques. Une utilisation trop laxiste de ce genre de langage peut mettre 
en peril la maintenabilite d'une application. 
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Conclusion 

Nous avons approfondi dans ce chapitre nos connaissances du conteneur leger de Spring. Bien 
que les techniques que nous avons vues soient variees, elles peuvent etre combinees dans une 
meme application afin de repondre aux problematiques parfois complexes de configuration. 

Les notions introduites dans ces deux chapitres sur le conteneur leger de Spring laissent bien 
apparaitre sa puissance et ses nombreuses possibilites. Nous avons constate qu'il existe gene- 
ralement plusieurs facons d'accomplir la meme chose. II s'agit la a la fois d'un avantage et 
d'un inconvenient. Avec de la pratique, chacun trouvera, parmi l'eventail propose par Spring, 
la solution la mieux adaptee a ses gouts et aux contraintes de son application. 

Nous abordons dans les deux chapitres suivants le support offert par Spring pour la program- 
mation orientee aspect. II s'agit la encore de decouvrir un nouveau paradigme, ameliorant 
fortement la modularite, la robustesse et la souplesse de nos applications. 



4 

Les concepts de la POA 



La POA (programmation orientee aspect), ou AOP (Aspect-Oriented Programming), est un 
paradigme dont les fondations ont ete definies au centre de recherche Xerox, a Palo Alto, 
au milieu des annees 1990. Par paradigme, nous entendons un ensemble de principes qui 
structurent la maniere de modeliser les applications informatiques et, en consequence, la 
facon de les developper. 

La POA a emerge a la suite de differents travaux de recherche, dont l'objectif etait 
d'ameliorer la modularite des logiciels arm de faciliter la reutilisation et la maintenance. 
Elle ne remet pas en cause les autres paradigmes de programmation, comme l'approche 
procedurale ou l'approche objet, mais les etend en offrant des mecanismes complemen- 
taires pour mieux modulaiiser les differentes preoccupations d'une application et ameliorer ainsi 
leur separation. 

Le conteneur leger de Spring etant de conception orientee objet, il ne peut aller au-dela des 
limites fondamentales de ce paradigme. C'est la raison pour laquelle Spring dispose de 
son propre framework de POA, qui lui permet d' aller plus loin dans la separation des 
preoccupations. 

Pour les lecteurs qui ne connaitraient pas ce paradigme de programmation, ce chapitre donne 
une vision synthetique des notions cles de la POA disponibles avec Spring. Nous invitons 
ceux qui desireraient en savoir plus sur la POA a lire l'ouvrage Programmation orientee 
aspect pour Java/J2EE, publie en 2004 aux editions Eyrolles. 

Comme nous Favons fait au chapitre 1 pour les concepts des conteneurs legers, nous 
commencons par decrire les problematiques rencontrees par les approches classiques de 
modelisation puis montrons en quoi la POA propose une solution plus elegante, avec ses 
notions d'aspect, de point de jonction, de coupe, de greffon et d' introduction. 
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Limites de I'approche orientee objet 

Une bonne conception est une conception qui minimise la rigidite, la fragilite, l'immobilite et 
l'inverifiabilite d'une application. 

L' ideal pour une modelisation logicielle est d'aboutir a une separation totale entre les diffe- 
rentes preoccupations d'une application afin que chacune d'elles puisse evoluer sans impacter 
les autres, perennisant ainsi au maximum le code de 1' application. 

Typiquement, une application recele deux sortes de preoccupations : les preoccupations d'ordre 
fonctionnel et les preoccupations d'ordre technique. Une separation claire entre ces deux types de 
preoccupations est souhaitable a plus d'un titre : le code metier est ainsi perennise par rapport aux 
evolutions de la technique, les equipes de developpement peuvent etre specialises (equipe pour 
le fonctionnel distincte de l'equipe s'occupant des preoccupations techniques), etc. 

Grace a l'inversion de controle, les conteneurs legers apportent une solution elegante a la 
gestion des dependances et a la creation des objets. lis encouragent la separation claire des 
differentes couches de 1' application, aidant ainsi a la separation des preoccupations, comme 
nous avons pu le voir au chapitre 1 . 
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La modelisation illustree a la figure 4-1 montre clairement que les preoccupations d'ordre 
technique, en F occurrence la persistance des donnees centralisee dans les DAO, sont claire- 
ment isolees des preoccupations fonctionnelles, representees par les classes metier Role, User 
et TodoList ainsi que la classe UserManagerlmpl . 

Cependant, les conteneurs legers restent de conception orientee objet et souffrent des insuffi- 
sances de cette approche. Ainsi, la separation des preoccupations techniques et fonctionnelles 
n'est pas toujours etanche. Nous allons montrer que l'approche orientee objet ne fournit pas 
toujours de solution satisfaisante pour aboutir a des programmes clairs et elegants. C'est 
notamment le cas de Fintegration des fonctionnalites transversales, problematique directement 
adressee par la POA. 

Integration de fonctionnalites transversales 

Nous qualifions de transversales les fonctionnalites devant etre offertes de maniere similaire 
par plusieurs classes d'une application. Parmi les fonctionnalites transversales que nous 
rencontrons souvent dans les applications, citons notamment les suivantes : 

• Securite. L'objet doit s'assurer que Futilisateur a les droits suffisants pour utiliser ses 
services ou manipuler certaines donnees. 

• Integrite referentielle. L'objet doit s'assurer que ses relations avec les autres sont cohe- 
rentes par rapport aux specifications du modele metier. 

• Gestion des transactions. L'objet doit interagir avec le contexte transactionnel en fonction 
de son etat (valide : la transaction continue ; invalide : la transaction est invalidee, et les 
effets des differentes operations sont annules). 

Avec l'approche orientee objet, ces fonctionnalites sont implementees dans chaque classe 
concernee, au moins sous forme d'appels a une bibliotheque ou un framework specialises. 
Une evolution de ces fonctionnalites transversales implique la modification de plusieurs 
classes. Par ailleurs, nous pouvons constater que ces fonctionnalites transversales sont des 
preoccupations en elles-memes. Le fait qu'elles soient prises en charge par des classes destinees 
a repondre a d'autres preoccupations n'est done pas satisfaisant. 

Exemple de fonctionnalite transversale dans Tudu Lists 

Pour mieux apprehender ce probleme, imaginons que nous desirions faire evoluer Tudu Lists 
de telle sorte que l'application supporte le declenchement de traitements en fonction d'evene- 
ments techniques ou fonctionnels. Lidee est de permettre a des objets de s'inscrire aupres 
d'un DAO ou d'un service afin de reagir en fonction des appels a ses methodes. 

Le traitement transversal que nous allons effectuer est une notification, que nous allons ajou- 
ter au service gerant les utilisateurs de TuduLists, UserManagerlmpl . II peut etre interessant que 
la creation d'un utilisateur provoque une notification, par exemple Fenvoi d'un e-mail a 
Fadministrateur. Cette notification pourrait avoir plusieurs buts : prevenir Fadministrateur 
qu'il doit valider la creation du compte, lui permettre de suivre facilement F adoption de Tudu 
Lists dans son entreprise... 
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L' implementation de cette fonctionnalite passe par la creation de deux interfaces tres simples, 
Noti f i er et Message. La figure 4-2 presente sous forme de schema UML ces deux interfaces et 
quelques implementations possibles. 
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Le Notifier effectue une action quand sa methode notify est appelee, avec un Message en 
parametre. Ces interfaces sont tres simples et tres generiques (Message ne definit pas de 
methode). Le Message est un simple objet de transport de donnees. L implementation la plus 
simple consiste au transport d'une String : 

package tudu. service. notify. impl ; 
import tudu. service. notify .Message; 
public class StringMessage implements Message { 
private String message; 



public StringMessage(String message) { 
this. message = message; 

1 



public String getMessageO { 
return message; 

} 



public String toStringO { 
return message; 

} 

} 

Le Consol eNoti f i er affiche les Messages dans la console : 
package tudu. service. notify. impl ; 

import tudu. service. notify. Mess age; 
import tudu. service. notify .Notifier; 
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public class ConsoleNotifier implements Notifier { 



public void notify(Message message) { 

System. out .printl n (message. toSt ring ( ) ) ; 



Cette implementation est utile pour verifier manuellement que les notifications ont bien lieu. Une 
implementation comme CountNoti f i er, qui compte le nombre de notification, nous permettrait, par 
exemple, de faire des tests automatises, afin de verifier que les notifications sont effectives : 

package tudu. service. notify. impl ; 

import java.util .concurrent. atomic. Atomiclnteger; 
import tudu. service. notify .Message; 
import tudu. service. notify .Notifier; 

public class CountNotifier implements Notifier { 

private Atomiclnteger count = new AtomicInteger( ) ; 

public void notify(Message message) { 
count. incrementAndGet( ) ; 

} 

public int getCountO { 



D'autres Notifiers plus realistes sont, par exemple, un Notifier envoyant un e-mail ou un 
Notifier envoyant un message sur une pile JMS. Si plusieurs notifications sont necessaires, il 
est possible d'implementer un Notifier composite, qui contient un ensemble de Notifiers et 
leur delegue le traitement des messages : 

package tudu. service. notify. impl ; 

import java.util .LinkedHashSet; 
import java.util .Set; 
import tudu. service. notify .Message; 
import tudu. service. notify .Notifier; 

public class CompositeNotifier implements Notifier { 

private Set<Notifier> notifiers = new LinkedHashSet<Notifier>( ) ; 

public void notify(Message message) { 
for (Notifier notifier : notifiers) { 
notifier. notify(message) ; 

} 



return count.getO; 
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) 



public void addNotifier( Notifier notifier) { 
notifiers.add(notifier) ; 

} 

public void setNotifiers(Set<Notifier> notifiers) { 
this.notifiers = notifiers; 

) 



} 



L'interface Message etant tres generique, il faut que le createur du Message et les Notifiers 
s'entendent sur la teneur de ce message, afin de pouvoir Fexploiter correctement. C'est une 
des limites de ce systeme. 

II est aussi possible d'utiliser la publication d'evenements proposee par le contexte d'applica- 
tion de Spring, mais cette publication est davantage adaptee aux evenements impactant 
Fensemble de l'application (rafraichissement de contexte, par exemple) qu'aux evenements 
dont la granularite est fine. 

Les principes de la notification etant definis, nous allons les appliquer pour developper notre 
fonctionnalite transversale et analyser ses effets sur la qualite de conception de Tudu Lists. 

Implementation objet de la notification dans Tudu Lists 

La notification doit avoir lieu lors de la creation d'un utilisateur. Cette creation est effectuee a 
Fappel de la methode createUser de la classe UserManagerlmpl . Le diagramme UML de la 
figure 4-3 montre comment le systeme de notification peut etre branche sur UserManagerlmpl . 
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Pour ameliorer la lisibilite de cette figure, nous n'avons pas mentionne F ensemble des methodes 
de UserManagerlmpl . 

UserManagerlmpl doit subir quelques modifications pour pouvoir effectuer la notification. II lui 
faut notamment une propriete Notif ier et le modificateur correspondant : 

package tudu. service. impl ; 
(...) 

import tudu. service. notify .Message; 
import tudu. service. notify. Notif ier; 

public class UserManagerlmpl implements UserManager { 

private Notif ier notif ier; 

public void setNotifier(Notifier notifier) { 
this.notifier = notifier; 

} 

} 

Ensuite, la notification doit etre directement effectuee au sein du code de la methode 
createUser (a la fin de celle-ci) : 

public void createLlserdJser user) 

throws UserAlreadyExistsException { 
User testUser = userDAO.getUser(user .getLogin( ) ) ; 
if (testUser != null ) { 

throw new UserAlreadyExistsExceptionCUser already exists."); 

} 

user. set Enabled (true) ; 
(...) 

use rDAO. saveUser( user) ; 

// creation de donnees de base 
TodoList todoList = new TodoListO; 
todoLi st .setName( "Wei come! " ) ; 
(...) 

todoListDAO.saveTodoList( todoList) ; 
(...) 

Todo welcomeTodo = new TodoO; 

welcomeTodo.setDescriptionC'Welcome to Tudu Lists!"); 
(...) 

todoListDAO.updateTodoLi st( todoList) ; 



// notification 

Message message = new StringMessage( 

"Creation de 1 ' uti 1 isateur"+user .getLogin( ) 

); 

notif ier. notify (message) ; 
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Dans le contexte Spring, il faut declarer le Notifier et l'assigner au UserManagerlmpl (il aurait 
aussi ete possible d'utiliser de Y autowiring) : 

<bean id="notif ier" 

class-"tudu. service. notify .impl .ConsoleNotifier"/> 

<bean id="userManager" cl as s="tudu. service. impl .UserManagerlmpl "> 

<property name="notifier" ref="notifier" /> 

<!-- injection des DAO --> 

(...) 
</bean> 

Le UserManagerlmpl est maintenant capable d'envoyer des notifications lorsqu'un utilisateur 
est cree. Cette approche evenementielle est interessante, car elle decouple Femetteur de 
messages et les objets en attente de notification. Le raisonnement par interface et F utilisation 
de Spring pour Finjection de dependances appuie plus encore ce decouplage, rendant Fapproche 
objet aussi souple que possible. 

Critique de ('implementation orientee objet 

L implementation de la notification n'est guere compliquee, quoiqu'un peu fastidieuse, 
puisqu'elle demande des modifications de code et de configuration. Si nous nous interessons 
a la qualite de la conception, nous nous apercevons que celle-ci n'est pas totalement satisfai- 
sante, bien qu'elle respecte Fetat de Fart en termes de conception orientee objet. 

Le probleme conceptuel reside dans la modelisation de Fobjet emetteur de la notification. 
Idealement, la notification devrait etre transparente pour la classe emettrice. Mais, d'une part, 
la notification est une problematique trans versale, et, d' autre part, d'autres classes sont 
susceptibles d'emettre des notifications. Or, comme nous pouvons le constater en analysant 
F implementation orientee objet precedente, toute nouvelle classe emettant des notifications 
necessite des modifications de structure, de code et de configuration. 

Par ailleurs, le moment ou la notification est emise est defini en dur dans le code de la classe 
emettrice. Si nous desirons changer ce moment, par exemple en notifiant avant un traitement 
plutot qu'apres, il est necessaire de modifier directement la classe. 

Enfin, F implementation de Message utilisee est fixee dans le code. Si la construction du 
message s'avere complexe, une partie du code de la classe emettrice risque d'etre dediee a 
cette construction. 

Si nous faisons une rapide analyse de cette modification de notre conception, nous constatons une 
degradation de la qualite de la modelisation : 

• Le modele est devenu plus rigide et fragile, car la generation de la notification est etroite- 
ment liee au code de chaque methode emettrice. II faut done veiller qu'une modification de 
ce code n'entraine pas de dysfonctionnement de la generation des messages (suppression 
malencontreuse de l'appel a la methode noti fy, par exemple). 

• L'immobilite du modele est augmentee puisque la notification devient partie integrante du 
service. Si nous desirons faire une version de Tudu Lists sans notification, nous sommes 
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contraints de conserver la mecanique d' observation, sauf a la supprimer directement dans le 
code ou a passer par une implementation de Notifier completement passive. 

• La verification du fonctionnement du service est rendue plus difficile, augmentant d'autant 
l'inverifiabihte du modele, dans la mesure ou il est necessaire de prendre en compte dans 
les tests le Notifier, en fournissant, par exemple, un simulacre (voir le chapitre 6 consacre 
aux tests). 

Alors que la separation des interfaces et des implementations couplee avec Finjection de 
dependances ont pour objectif de rendre les classes les plus independantes possible, nous 
constatons qu'un principe de notification n'est pas correctement modularise et genere un 
phenomene de dispersion du code au fur et a mesure de son utilisation pour differentes classes 
de Tudu Lists. 



Analyse du phenomene de dispersion 

Partant d'un tel constat, il est legitime de se demander si une meilleure conception et un autre 
decoupage des classes de F application ne permettraient pas de faire disparaitre cette dispersion du 
code. La reponse est malheureusement le plus souvent negative. 

La raison qui tend a prouver que la dispersion du code est ineluctable est liee a la difference 
entre service offert et service utilise. Une classe fournit, via ses methodes, un ou plusieurs 
services. II est aise de rassembler tous les services fournis dans un meme endroit, c'est-a-dire 
dans une meme classe. Cependant, rien dans l'approche objet ne permet de rassembler les 
utilisations de ce service. II n'est done pas surprenant qu'un service general et d'utilisation 
courante soit utilise partout. 

La dispersion d'une fonctionnalite dans une application est un frein a son developpement, a sa 
maintenance et a son evolutivite. Lorsque plusieurs fonctionnalites sont dispersees, la situa- 
tion empire. Le code ressemble alors a un plat de spaghettis, avec de multiples appels a diver- 
ses API. II devient embrouille (en anglais tangled). Ce phenomene se manifeste dans de 
nombreuses applications. 

II devient done evident qu'une nouvelle dimension de modularisation doit etre creee ann de 
capturer les fonctionnalites trans versales au sein d'entites specifiques preservant la flexibilite 
de la conception de 1' application. 

En resume 

L'approche orientee objet a apporte un niveau de modularisation important grace a la notion 
d'objet et aux mecanismes associes (heritage, polymorphisme, etc.). Cependant, cette appro- 
che est grevee de limitations fondamentales, qui apparaissent des qu'il s'agit de modulariser 
les preoccupations transversales d'une application. Celles-ci sont generalement dispersees au 
sein du code, rendant leur maintenance et leur evolution dedicates. 

La POA introduit de nouvelles notions offrant une dimension supplementaire de modularisation 
adaptee a ces problematiques. 
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Notions de base de la POA 

Pour repondre ail besoin de modularisation des fonctionnalites trans vers ales, la POA a intro- 
duit de nouvelles notions, qui viennent en complement de celles de l'approche objet. 

Dans cette section, nous presentons ces nouvelles notions en montrant comment elles inter- 
viennent pour ameliorer l'integration de fonctionnalites transversales, comme l'exemple de 
notification. 

Outre la notion d' aspect, equivalent de la notion de classe en POO, nous detaillons les notions 
de point de jonction, de coupe, de greffon, aussi appele code advice, et d' introduction, qui 
sont au cceur de la notion d' aspect, au meme titre que les attributs ou les methodes le sont a 
celle de classe. 



La notion d'aspect 

Pour apprehender la complexite d'un programme, nous cherchons generalement a le decouper 
en sous-programmes de faille moins importante. Les criteres a appliquer pour arriver a cette 
separation ont fait l'objet de nombreuses etudes, visant a faciliter la conception, le developpe- 
ment, la maintenance et l'evolutivite des programmes. 

La programmation procedurale induit un decoupage en fonction des traitements a implemen- 
ter, tandis que la programmation objet induit un decoupage en fonction des donnees qui seront 
encapsulees dans les classes avec les traitements associes. Comme nous l'avons vu, certaines 
fonctionnalites s'accommodent mal de ce decoupage, et les instructions correspondant a leur 
utilisation se retrouvent dispersees dans 1' ensemble de 1' application. Tout changement dans 
F utilisation de ces fonctionnalites implique de devoir consulter et modifier un grand nombre 
de fichiers. 

Lapport essentiel de la POA est de fournir un moyen de rassembler dans une nouvelle entite 
F aspect, le code d'une fonctionnalite transversale, habituellement disperse au sein de F appli- 
cation, et les approches classiques de programmation. 



Aspect 

Entite logicielle qui capture une fonctionnalite transversale a une application. 



La definition d'un aspect est presque aussi generate que celle d'une classe. Une classe est un 
element du probleme a modeliser (la clientele, les commandes, les fournisseurs, etc.), auquel 
nous associons des donnees et des traitements. De meme, un aspect est une fonctionnalite a 
mettre en ceuvre dans une application (la securite, la persistance, etc.), dont 1' implementation 
comprendra les donnees et les traitements relatifs a cette fonctionnalite. 

En POA, une application comporte des classes et des aspects. Un aspect se differencie d'une 
classe par le fait qu'il implemente une fonctionnalite transversale a l'application, c'est-a-dire 
une fonctionnalite qui, en programmation orientee objet ou procedurale, serait dispersee dans 
le code de cette application. 
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La presence de classes et d' aspects dans une meme application introduit done deux dimen- 
sions de modularite : celle des fonctionnalites implementees par les classes et celle des fonc- 
tionnalites trans vers ales implementees par les aspects. 

La figure 4-4 illustre l'effet d'un aspect sur le code d'une application. La partie gauche de la 
figure schematise une application composee de trois classes. Les filets horizontaux represen- 
tent les lignes de code correspondant a une fonctionnalite, par exemple la gestion des traces. 
Cette fonctionnalite est trans versale a 1' application, car elle affecte toutes ses classes. La 
partie droite de la figure montre la meme application apres ajout d'un aspect de gestion des 
traces (rectangle noir). Le code de cette fonctionnalite est maintenant entierement localise 
dans F aspect, et les classes sont vierges de toute intrusion. Une application ainsi concue avec 
un aspect est plus simple a ecrire, maintenir et faire evoluer qu'une application sans aspect. 



Figure 4-4 

Impact d'un 
aspect sur la 
localisation d'une 
fonctionnalite 
transversale 



Sans aspect 



Avec aspect 



Dans notre exemple d' implementation de notification, l'utilisation d'un aspect permet de lais- 
ser inchange le code de la classe lancant une notification (interface et implementation, en 
l'occurrence UserManager et UserManagerlmpl). Par ailleurs, le Notifier n'est plus lie a la 
classe manager, mais directement a 1' aspect. 

Le diagramme de classes illustre a la figure 4-5 montre les effets de la modularisation de 
1' implementation de la notification dans Tudu Lists. 

Grace a cette nouvelle dimension de modularisation, la separation des preoccupations est 
maintenue, avec un modele metier qui conserve son expressivite originelle et sur lequel 
s'interfacent des extensions clairement identifiees apportees par l'aspect. Ces extensions, 
transparentes pour les managers — notons F inversion de controle au profit de l'aspect — , 
permettent une reutilisation de la fonctionnalite transversale sans dispersion du code. 

Nous verrons dans la suite de ce chapitre que deux elements entrent dans l'ecriture d'un 
aspect, la coupe et le greffon, ou code advice. La coupe definit le caractere transversal de 
l'aspect, e'est-a-dire les endroits de 1' application dans lesquels la fonctionnalite transversale 
doit s'integrer, tandis que le greffon fournit le code proprement dit de cette derniere. 
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Figure 4-5 

Modelisation de la 
notification sous forme 
d' aspect dans Tudu Lists 
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Les points de jonction 

Nous avons vu qu'un aspect etait une entite logicielle implementant une fonctionnalite trans- 
versale a une application. La definition de cette structure transversale passe par la notion de 
point de jonction. 



Point de jonction (join point) 

Point dans I'execution d'un programme autour duquel un ou plusieurs aspects peuvent etre ajoutes. 



Nous verrons a la section suivante qu'il existe differents types de points de jonction. II peut 
s'agir, par exemple, de points dans I'execution d'un programme ou une methode est appelee. 

La notion de point de jonction est tres generate. Elle peut etre comparee a celle de point 
d'arret d'execution, qui, lors de la mise au point d'un programme a l'aide d'un debogueur, 
designe un endroit du code source ou nous souhaitons voir I'execution s'arreter. Dans le cadre 
de la POA, un point de jonction designe un endroit du programme ou nous souhaitons ajouter 
un aspect. L'analogie s'arrete la. L' emplacement du point d'arret est fourni de fa5on interac- 
tive par le developpeur via un numero de ligne dans le code source. En POA, le point de jonction 
est fourni de maniere « programmatique » par le developpeur. 

Si, en theorie, rien n'empeche d'utiliser les numeros de ligne du code source pour definir un 
point de jonction, aucun des outils de POA existants ne le permet. Le cout a payer, en termes 
de perte de performance a I'execution et de complexite d'implementation de Foutil, est juge 
prohibitif. De surcroit, la moindre modification dans les numeros de ligne du code source 
imposerait une mise a jour couteuse de la definition des points de jonction. 
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Les differents types de points de jonction 

En faisant reference a l'execution d'un programme, la notion de point de jonction revele son 
caractere eminemment dynamique. II s'agit d'evenements qui surviennent une fois le 
programme lance. Lorsqu'il s'agit de definir concretement et de maniere « programmatique » 
un point de jonction, il est necessaire de s'appuyer sur la structure des programmes. Dans 
80 % des cas, nous nous appuyons sur des methodes. 

Dans notre implementation de la notification, les points de jonction a utiliser pour 1' aspect de 
notification sont les appels a la methode de creation d'un utilisateur dans UserManager. 

Les methodes ne sont pas les seuls elements qui structurent les programmes orientes objet. 
Classes, interfaces, exceptions, attributs, blocs de code et instructions (for, while, if, switch, 
etc.) en font egalement partie. Avec Spring AOP, il n'existe en standard qu'un seul point de 
jonction (execution de methodes). Cependant, d'autres outils de POA, tels qu'AspecJ ou 
JBoss AOP, supportent d'autres points de jonction, comme les attributs, ou plus exactement 
leurs acces en lecture ou en ecriture. 

Aussi simple soit-il, un programme comporte de nombreux points de jonction potentiels. La 
tache du programmeur d' aspects consiste a selectionner les points de jonction pertinents pour 
son aspect. La section suivante s'interesse a la facon dont s'opere cette selection. Celle-ci 
passe par la notion de coupe. 

Les coupes 

Nous avons vu que les points de jonction etaient des elements lies a l'execution d'un 
programme, autour desquels nous souhaitons greffer un aspect. En ce qui concerne 1' ecriture 
du code de 1' aspect, il est necessaire de disposer d'un moyen pour designer de maniere 
concrete les points de jonction a prendre en compte. Ce moyen est fourni par la coupe. 



Coupe (pointcut) 

Designe un ensemble de points de jonction. 



Une coupe est definie a l'interieur d'un aspect. Dans les cas simples, une seule coupe suffit 
pour definir la structure transversale d'un aspect. Dans les cas plus complexes, un aspect est 
associe a plusieurs coupes (chacune definit un ensemble de methodes par exemple). 

Les notions de coupes et de points de jonction sont liees par leur definition. Pourtant, leur 
nature est tres differente. Une coupe est un element de code defini dans un aspect, alors qu'un 
point de jonction est un point dans l'execution d'un programme. Si une coupe designe un 
ensemble de points de jonction, un point de jonction donne peut appartenir a plusieurs coupes 
d'un meme aspect ou d' aspects differents. Dans ce cas, comme nous le verrons dans la suite 
de ce chapitre, il est necessaire de definir l'ordre d' application des differentes coupes et des 
differents aspects autour des points de jonction. 

Generalement, la coupe se definit via une syntaxe appropriee a la definition de methodes (car 
avec Spring AOP, seuls les points de jonction de type methode sont supportes). En faisant un 
parallele avec une recherche de fichiers, l'expression * . j ava permet de definir un ensemble de 
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fichiers Java. Pour definir une coupe, nous pouvons utiliser l'expression UserManagerlmpl .* 
pour definir l'ensemble des methodes de la classe UserManagerlmpl . Chacune des methodes est 
un point de jonction. 

II est possible d' utiliser differentes syntaxes pour definir une coupe, il suffit que Foutil de 
POA les comprenne. Les expressions regulieres sont une solution possible. Cependant, la 
solution la plus adaptee est une syntaxe dediee a la designation de packages, de classes et de 
methodes, ce qui est le cas de la syntaxe AspectJ. 

Les greffons 

Nous avons vu qu'une coupe definissait ou un aspect devait etre greffe dans une application. 
La coupe designe pour cela un ensemble de points de jonction. Le greffon, ou code advice, 
definit quant a lui ce que 1' aspect greffe dans 1' application, autrement dit les instructions ajou- 
tees par F aspect. Si F aspect represente conceptuellement la fonctionnalite transversale ajoutee, le 
greffon est veritablement F implementation de cette fonctionnalite. 



Greffon (code advice) 

Bloc de code definissant le comportement d'un aspect. 



Un aspect comporte un ou plusieurs greffons. Chaque greffon definit un comportement parti- 
culier pour son aspect. Le greffon joue en quelque sorte le meme role qu'une methode. A la 
difference des methodes, cependant, les greffons sont associes a une coupe, et done a des 
points de jonction, et ont un type. D'un point de vue plus abstrait, il convient de noter que si 
une methode definit une fonctionnalite a part entiere, un greffon definit plutot Fintegration 
d'une fonctionnalite a priori transversale. 

Chaque greffon est associe a une coupe. La coupe fournit l'ensemble des points de jonction 
autour desquels sera greffe le bloc de code du greffon. Une meme coupe peut etre utilisee par 
plusieurs greffons. Dans ce cas, differents traitements sont a greffer autour des merries points 
de jonction. Cette situation pose le probleme de la composition d'aspect, que nous n'abordons 
pas ici. 

Pour notre exemple, le greffon se reduit a l'equivalent de l'appel de la methode noti f y, realise 
precedemment directement dans le code de UserManagerlmpl. L'attribut notifier est bien 
entendu deplace dans F aspect, qui est, dans le cas de Spring AOP, une classe Java. 

Les differents types de greffon 

Avec Spring, il existe cinq types de greffons, qui se differencient par la facon dont le bloc de 
code est execute lorsque apparait un point de jonction de la coupe a laquelle ils sont associes : 

• before : le code est execute avant les points de jonction, e'est-a-dire avant l'execution des 
methodes. 

• after returni ng : le code est execute apres les points de jonction, e'est-a-dire apres l'execution 
des methodes. 
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• after throwing : le code est execute apres les points de jonction si une exception a ete 
generee. 

• after : le code est appele apres les points de jonction, meme si une exception a ete generee. 

• around : le code est execute avant et apres les points de jonction. 

Dans le cas des greffons around, il est necessaire de delimiter la partie de code qui doit etre 
executee avant le point de jonction et celle qui doit l'etre apres. Les outils de POA fournissent 
pour cela une instruction ou une methode speciale, nommee proceed (proceder, continuer). La 
methode proceed permet de revenir a l'execution du programme, autrement dit d'executer le 
point de jonction. 

Le deroulement d'un programme avec un greffon around peut etre resume de la facon 
suivante : 

1. Execution normale du programme. 

2. Juste avant un point de jonction appartenant a la coupe, execution de la partie avant 
du greffon. 

3. Appel a proceed. Cela declenche l'execution du code correspondant au point de jonction. 

4. Execution de la partie apres du greffon. 

5. Reprise de l'execution du programme juste apres le point de jonction. 

L'appel a proceed est facultatif, un code advice around pouvant parfaitement ne jamais appeler 
proceed. Dans ce cas, le code correspondant au point de jonction n'est pas execute, et le bloc 
du greffon remplace le point de jonction. Apres l'execution du greffon, le programme reprend 
son execution juste apres le point de jonction. 

Un greffon around peut aussi appeler proceed dans certaines situations et pas dans d'autres. 
C'est le cas, par exemple, d'un aspect de securite qui controle l'acces a une methode. Si l'utili- 
sateur est correctement authentifie, l'appel de la methode est autorise, et l'aspect invoque proceed. 
Si l'utilisateur n'a pas les bons droits, l'aspect de securite n'invoque pas proceed, ce qui a pour 
effet de ne pas executer le point de jonction et done de ne pas appeler la methode. 

Dans certains cas, proceed peut etre appele plusieurs fois. Cela peut s'averer utile pour des 
aspects qui ont a faire plusieurs tentatives d'execution du point de jonction, suite, par exemple, a 
des pannes ou a des erreurs d'execution. 

L'instruction proceed ne concerne pas les greffons before et after. Par definition, un code 
advice before n'a qu'une partie avant. II n'y a done pas de partie apres a delimiter. Un code 
advice before est automatiquement greffe avant le point de jonction. II en va de meme des 
codes advice after, qui n'ont qu'une partie apres. 

Notons que le type around est l'union des types before et after. II est done tentant de n'utiliser 
que le type around, puisqu'il est en mesure d'offrir les memes services que before et after. 
Nous deconseillons toutefois fortement cette pratique, car cela nuit a la bonne comprehension 
du role et des effets du greffon dans 1' application. 

Dans notre exemple, le type de greffon a utiliser est after returning. En effet, l'utilisation du 
type around est trop generique pour notre besoin. Quant a l'utilisation du type before, elle 
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s'avere risquee puisque la methode peut ne pas realiser la creation de l'utilisateur, par exem- 
ple en generant une exception. 

Le mecanisme d' introduction 

Les mecanismes de coupe et de greffon que nous avons vus jusqu'a present permettent de 
definir des aspects qui etendent le comportement d'une application. Les coupes designent des 
points de jonction dans l'execution de l'application, tandis que les greffons ajoutent du code 
avant ou apres ces points. 

Dans tous les cas, il est necessaire que les codes correspondant aux points de jonction soient 
executes pour que les greffons le soient egalement. Si les points de jonction n'apparaissent 
jamais, les greffons ne sont jamais executes, et l'aspect n'a aucun effet sur l'application. 

Le mecanisme d'introduction permet d'etendre le comportement d'une classe en modifiant sa 
structure, c'est-a-dire en lui ajoutant des elements, essentiellement des attributs ou des metho- 
des. Dans le cas de Spring AOP, nous ne pouvons introduire que de nouvelles interfaces avec 
F implementation associee. Ces changements structurels sont visibles des autres classes, et 
celles-ci peuvent les utiliser au meme titre que les elements originels de la classe. Contraire- 
ment aux greffons, qui etendent le comportement d'une application si et seulement si certains 
points de jonction sont executes, le mecanisme d'introduction est sans condition, et l'exten- 
sion est realisee dans tous les cas. Le terme introduction renvoie au fait que ces elements sont 
introduits, c'est-a-dire ajoutes a la classe. 

Comme le mecanisme d'heritage des langages de programmation orientee objet, le meca- 
nisme d'introduction de la POA permet d'etendre une classe. Neanmoins, contrairement a 
l'heritage, l'introduction ne permet pas de redefinir une methode. L introduction est done un 
mecanisme purement additif, qui ajoute de nouveaux elements a une classe. 

Dans notre exemple, nous pouvons transformer une classe quelconque de Tudu Lists en Notifier. 
En effet, grace au mecanisme d'introduction, nous pouvons lui faire implementer l'interface 
Notifier sans modifier son code source. L implementation de la methode notify de cette 
interface est assuree au sein de l'aspect par un greffon d'un type particulier, appele mix-in. 

Le tissage d'aspect 

Une application en POA est composee d'un ensemble de classes et de un ou plusieurs aspects. 
Une operation automatique est necessaire pour obtenir une application operationnelle, inte- 
grant les fonctionnalites des classes et celles des aspects. 

Cette operation est designee sous le terme de tissage (en anglais weaving). Le programme qui 
la realise est un tisseur d'aspects (en anglais aspect weaver). L'application obtenue a Tissue 
du tissage est dite tissee. 



Tisseur d'aspects {aspect weaver) 

Programme qui realise une operation d'integration entre un ensemble de classes et un ensemble 
d'aspects. 
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L' operation de tissage peut etre effectuee a la compilation ou a Fexecution. Dans le cas de 
Spring AOP, le tissage s'effectue uniquement a Fexecution, au sein du conteneur leger. Le 
conteneur leger controlant Finstanciation des classes de Fapplication, il est en mesure de 
declencher le tissage des aspects si necessaire. Bien entendu, lorsqu'une classe est directe- 
ment instanciee dans Fapplication, sans passer par le conteneur leger, le tissage ne peut 
s'effectuer. 

Le tissage effectue par Spring AOP repose sur F utilisation de proxy dynamiques crees avec 
FAPI standard Java SE (voir la classe jdva.lang. reflect. Proxy). Ces proxy dynamiques 
interceptent les appels aux methodes de Finterface, appellent les greffons implementes par les 
aspects et redirigent, en fonction du type de greffon, les appels a la classe implementant 
Finterface. 

Pour illustrer ce mode de fonctionnement, supposons que nous ayons une interface appelee 
Unelnterface, une classe appelee Unelmpl implementant cette interface et un aspect dont la 
coupe porte sur Fappel a la methode uneMethode de Unelnterface. 

Lors de Finjection des dependances, au lieu de renvoyer directement une instance de Unelmpl , 
le conteneur leger genere un proxy dynamique de Finterface Unelnterface. Ce proxy dynami- 
que intercepte les appels a Fensemble des methodes definies dans Unelnterface. Quand 
uneMethode est appelee, le proxy execute le greffon associe a la coupe. Si le greffon est de type 
before, il est execute en premier, puis Fappel est redirige vers Unelmpl. Si le greffon est de 
type after, Fappel est redirige vers Unelmpl, puis le greffon est execute. Si le greffon est de 
type around, seul le greffon est appele par le proxy, charge au premier de rediriger Fappel a 
Unelmpl via Finstruction proceed. 

L'utilisation de proxy dynamiques par le biais de FAPI Java SE ne fonctionne qu'avec des 
interfaces. Pour effectuer un tissage sur une classe sans interface, Spring AOP utilise la biblio- 
theque open source CGLIB (Code Generation Library) pour generer le proxy. 

Grace a son mode de fonctionnement, Spring AOP peut etre utilise sans difficulte au sein d'un 
serveur d' applications, ce qui n'est pas toujours le cas des autres outils de POA effectuant un 
tissage a Fexecution. Du fait de leur fonctionnement en dehors d'un conteneur leger, ils ont 
besoin de controler le chargeur de classes pour effectuer le tissage a Fexecution. Malheureu- 
sement, cette operation n'est pas toujours possible avec les serveurs d' applications. 

Utilisation de la POA 

Comme tout nouveau paradigme de programmation, la POA necessite un temps d'apprentis- 
sage non negligeable avant de pouvoir etre utilisee de maniere efficace. Par ailleurs, les outils 
de POA ne jouissent pas d'un support pousse dans les environnements de developpement, a 
l'exception notable d'AspectJ, Foutil pionnier de la POA, ce qui ne facilite pas le travail des 
developpeurs, notamment dans la mise au point des programmes. 

Spring AOP, non content de fournir une implementation des concepts fondamentaux de la 
POA, propose un certain nombre d'aspects prets a Femploi. Dans le package 
org. springf ramework.aop. interceptor, nous disposons d'aspects de debogage, de trace et de 
monitoring de performance. Dans le package org. springf ramework. transact! on. interceptor, 
nous trouvons F implementation en POA de la gestion des transactions. 
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Pour une initiation a Futilisation de la POA dans des projets, nous recommandons de 
commencer par ces aspects, qui ont fait leurs preuves. Nous aurons l'occasion de les aborder 
plus en detail au fil de cet ouvrage. Pour aller plus loin et developper de nouveaux aspects, 
nous conseillons de commencer par des problematiques simples, sans impact direct sur la 
perennite de l'application, comme F implementation d'un systeme de conception par contrat. 

II est aussi possible d'implementer simplement certains design patterns en POA, avec a la cle 
de reels benefices. Outre notre exemple de notification, citons notamment les modeles de 
conception commande, chaine de responsabilite et proxy. L' ouvrage Programmation orientee 
aspect pour Java/J2EE en fournit des implementations pour AspectJ, mais elles sont aisement 
transposables pour Spring AOP 

En resume 

La POA introduit les notions nouvelles d' aspect, de point de jonction, de coupe, de greffon et 
d'introduction, qui permettent de modulariser correctement les fonctionnalites transversales 
au sein d'entites specifiques, les aspects. Ces notions viennent en complement de celles de 
Fapproche orientee objet, mais ne les remplacent pas. 

Au final, cette nouvelle dimension de modularisation apporte un degre d'inversion de controle 
supplementaire, puisqu'elle decharge les classes de F implementation de la fonctionnalite au 
profit d'entites exterieures, en Foccurrence les aspects. 

Conclusion 

Nous avons vu que Fapproche orientee objet, meme dotee de concepts pousses, comme ceux 
des conteneurs legers, n'apportait pas de solution satisfaisante a Fintegration de fonctionnali- 
tes transversales. Ces fonctionnalites rendent le code moins flexible et genent la separation 
claire des preoccupations du fait du phenomene de dispersion. La POA repond de maniere 
elegante a ces problematiques en introduisant le concept fondamental d' aspect, complemen- 
taire de ceux utilises par les langages de programmation orientes objet. 

Spring AOP fournit une implementation plus limitee de la POA que des outils tels qu' AspectJ 
(dont il integre cependant une partie des fonctionnalites), mais offre suffisamment de fonc- 
tionnalites dans son tisseur a F execution pour repondre a la plupart des besoins de modulari- 
sation sous forme d' aspects. Des fonctionnalites majeures de Spring sont d'ailleurs imple- 
mentees dans Spring AOP, comme la gestion des transactions. 

Spring AOP supporte les aspects crees avec Aspec J dans le conteneur leger afin de repondre 
aux besoins complexes en POA, ou s'il est necessaire d'operer le tissage a la compilation. 
L'un des grands avantages d' Aspec J est son support par Eclipse, qui le dote, via le plug-in 
AJDT, d' outils facilitant le developpement des aspects. Spring ne fournit pas d' integration 
pour d'autres outils de POA, tels que JBoss AOP. 

Nous decrivons en detail Spring AOP au chapitre suivant, dans lequel nous implementons 
sous forme d' aspect notre exemple de notification afin d'illustrer concretement les benefices 
apportes par la POA. 
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Le chapitre precedent a presente les concepts de la POA et montre comment ils permettaient 
d'ameliorer de maniere significative la qualite d'une application en apportant une nouvelle 
dimension de modularisation. C'est a partir de ces bases conceptuelles que nous abordons ici 
le support de la POA offert par Spring. 

Spring propose un framework 100 % Java, appele Spring AOP, permettant d'utiliser les 
concepts de la POA dans nos applications. Apres le succes d'AspectJ, pionnier en matiere de 
POA, Spring integre depuis sa version 2.0 les fonctionnalites majeures de cet outil dans son 
framework. Cependant, le support de la POA propose par Spring est plus limite que celui 
d'AspectJ en termes de points de jonction pour definir les coupes (Spring ne supporte qu'un 
seul type de point de jonction). En depit de ce support limite, Spring AOP couvre la majorite 
des besoins. 

Spring a la capacite de s'interfacer avec les aspects developpes directement avec AspectJ, 
mais nous n' abordons pas cette possibilite dans le cadre de cet ouvrage, F integration partielle 
d'AspectJ disponible avec Spring AOP se revelant suffisante. 

Les sections qui suivent proposent un tour d' horizon complet de la POA avec Spring et 
detaillent la mise en ceuvre de chaque concept de la POA, tels que aspect, coupe, greffon et 
introduction. 

Implementation de la notification avec Spring AOP 

Avant d'aborder 1' implementation de chacun des concepts de la POA avec Spring, nous allons 
entrer dans le vif du sujet en developpant un premier aspect implementant en POA l'exemple 
de notification que nous avons decrit au chapitre precedent. Ce premier aspect nous servira de 
fil directeur dans le reste du chapitre. 
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Nous avons vu ail chapitre precedent que 1' implementation de la notification n'etait pas plei- 
nement satisfaisante en recourant exclusivement a l'approche orientee objet. Nous avons alors 
introduit les concepts de la POA et montre qu'ils permettaient d' implementer cette fonction- 
nalite de maniere non intrusive arm d' assurer une meilleure separation des preoccupations au 
sein de F application. 

Pour realiser notre fonctionnalite, nous conservons la totalite du code fourni au chapitre 4, a 
savoir les interfaces Notifier et Message, ainsi que leurs differentes implementations. Par 
contre, les developpements realises dans la classe UserManagerlmpl sont maintenant geres sous 
forme d' aspect et doivent done etre reconsideres en utilisant les concepts de la POA. 

Comme indique en debut de chapitre, Spring AOP permet de developper un aspect de deux 
manieres : en utilisant le framework AOP de Spring ou en utilisant le support d'AspectJ 
propose par Spring. 

Le framework AOP de Spring correspond a la POA telle qu'elle existait dans Spring 1.2. Nous 
designerons cette approche sous le nom de Spring AOP classique. Nous incluons cette approche 
de facon que les lecteurs qui Font utilisee retrouvent leurs marques. 

Le support AspectJ de Spring AOP permet de beneficier tres simplement de la puissance du 
framework de POA le plus avance du monde Java. II tire parti des fonctionnalites de configu- 
ration des espaces de nommage et des annotations Java 5. 

Nous recommandons d'utiliser le support AspectJ pour tout nouveau projet plutot que Spring 
AOP classique. 



Implementation de I'aspect de notification avec Spring AOP classique 

Spring AOP etant un framework 100 % Java, done oriente objet, il caique les notions orientees 
aspect sur celles orientees objet. Ainsi, pour realiser des greffons, Spring AOP utilise des 
Beans devant implementer une interface specifique en fonction du type de greffon concerne. 

Dans notre exemple, nous devons realiser un greffon de type afterReturning, e'est-a-dire 
qu'une notification ne sera emise que si le code de la coupe s'execute sans generer d'excep- 
tion. Pour implementer ce type de greffon, Spring AOP dispose de F interface 
AfterReturningAdvice, definie dans le package org. spring-framework. aop, comme les autres 
types de greffons. Cette interface specifie une methode afterReturning, qui est appelee pour 
executer le code du greffon. 

Nous pouvons implementer notre greffon de la maniere suivante : 
package tudu. aspects. notify .classic; 

import java . 1 ang. ref 1 ect .Method ; 

import org. springf ramework. aop. AfterReturningAdvice; 

import tudu. service. notify .Notifier; 

import tudu. service. notify. impl .StringMessage; 

public class NotifierAdvice implements AfterReturningAdvice { 
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private Notifier notifier; 

public void setNotifier(Notifier notifier) { 
this. notifier = notifier; 

} 

public void afterReturning(Object returnValue, Method method, 
Object[] args, Object target) throws Throwable { 
notifier.notify( 

new StringMessageC'appel de "+method .getName( ) ) 

); 

} 

} 

Notre greffon est un Bean possedant une propriete Notifier, qui est initialisee par le conte- 
neur leger, comme nous le verrons plus loin. Cette propriete implementant toute la logique de 
notification, le seul travail de notre greffon est d'appeler sa methode notify. Notons que les 
parametres de la methode after Returning permettent d'acceder aux informations concernant 
la methode interceptee (valeur de retour, arguments, etc.). 

La configuration de ce greffon dans le conteneur leger s'effectue de la maniere suivante : 

<bean id="notifier" 

cl ass="tudu. service. notify . impl .ConsoleNotifier" /> 

<bean id="notifyAdvice" 

class="tudu. aspects. notify. classic.NotifierAdvice"> 
<property name="notifier" ref="notifier" /> 
</bean> 

Le Notifier est declare (F implementation utilisee est ConsoleNotifier) puis injecte dans 
1' aspect. 

Le moment auquel notre greffon sera execute est specifie sous forme d'une coupe. Dans notre 
exemple, ce moment correspond a l'execution de la methode de l'interface UserManager, a 
savoir createUser. Pour definir cette coupe, Spring AOP propose differentes classes a utiliser 
sous forme de Beans geres par le conteneur leger. Ainsi, le framework propose la classe 
NameMatchMethodPointcut, qui permet de definir une coupe sur une ou plusieurs methodes : 
<bean id="observerPointcut" 
cl ass="org.springf ramework.aop. support. NameMatchMethodPointcut"> 

<property name="mappedName" val ue="createUser" /> 

</bean> 

Nous utilisons la propriete mappedName, qui recoit le nom de la methode dont l'execution doit 
etre interceptee. La propriete mappedNames est aussi disponible pour definir - une liste de methodes, 
separees par des virgules. 
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Maintenant que nous avons defini le greffon et la coupe associee, nous pouvons les integrer au 
sein d'un aspect. Cette operation s'effectue en utilisant une des classes de Spring AOP prevue 
a cet effet et configurable dans le conteneur leger. 

Pour notre exemple, nous utilisons la classe DefaultPointcutAdvisor, qui permet d'associer 
un greffon et une coupe : 

<bean id="notifierAdvisor" 
cl a ss=" org. springframework.aop. support. DefaultPointcutAdvisor "> 

<property name="advice" ref="notifyAdvice" /> 
<property name="pointcut" ref="notifierPointcut" /> 

</bean> 

Cette classe dispose de deux proprietes : advice, contenant la reference au Bean greffon, et 
pointcut, contenant la reference au Bean coupe. 

Pour finir, il est necessaire d'indiquer a Spring AOP de realiser le tissage en instanciant un 
tisseur d' aspect dans le conteneur leger. Ce tissage peut etre manuel ou automatique (a partir 
des informations fournies par les coupes). 

Dans notre exemple, nous realisons un tissage automatique en nous aidant du tisseur 
Def aul tAd visor Auto Proxy Creator : 

<bean class=" 

org. spring-framework, aop. framework, autoproxy . Def aul tAdvisorAutoProxyCreator"/> 

Grace a ce tisseur, toutes les classes possedant des methodes ayant les noms specifies dans la 
coupe seront interceptees. II faut toutefois prendre garde au perimetre de F interception. 
Heureusement, dans Tudu Lists, le nom fourni n'est utilisee que par UserManager. 

La creation d'un utilisateur fait maintenant l'objet d'une notification (dans notre exemple, un 
simple message dans la console). Force est de constater que l'ajout de notification s'est 
fait tres simplement (quelques lignes de configuration) et surtout sans modification du 
code existant. 



Implementation de I'aspect de notification avec le support AspectJ 
de Spring AOP 

Depuis sa version 2.0, Spring permet d'utiliser certains elements d' AspectJ pour creer des 
aspects sans necessiter F utilisation directe de cet outil. Cette integration est disponible sous 
deux formes : une forme XML, utilisant un schema specifique, et une forme utilisant les anno- 
tations Java 5 definies par AspectJ. La premiere forme a Favantage d'etre compatible avec les 
anciennes versions de Java, tandis que la seconde beneficie de la compatibilite avec AspectJ 
(un aspect defini sous forme d' annotations est directement compilable avec AspectJ). 

Pour notre exemple, nous utilisons la premiere forme, la seconde etant abordee ulterieurement 
dans ce chapitre. Quelle que soit la forme utilisee, le support d' AspectJ utilise des Beans geres 
dans le conteneur leger pour implementer les differentes notions de la POA. Le mapping entre 
Beans et notions de POA s'effectue au sein du fichier de configuration. 
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Contrairement a Spring AOP, le support AspectJ ne necessite pas d' interfaces speciflques pour 
les Beans composant F aspect. Notre greffon se code done plus simplement que 
precedemment : 

package tudu. aspects . notify . aspect j ; 

import org. aspect j . 1 ang. Join Point ; 

import tudu. service. notify .Notifier; 

import tudu. service. notify. impl .StringMessage; 

public class Notif ierAdvice { 

private Notifier notifier; 

public void setNotifier(Notifier notifier) { 
this. notifier = notifier; 

} 

public void handleNotification(JoinPoint jp) { 
notifier. notify (new StringMessage( 

"appel de "+jp.getSignature( ) .getName( ) 

)); 

} 

} 

L'equivalent de la methode afterReturning de l'exemple precedent est la methode 
handleNotifi cation. Cette methode a pour parametre un org. aspect. 1 ang. JoinPoint (point 
de jonction) qui permet de disposer d' informations sur la methode interceptee (nom, parame- 
tres, etc.). Ce parametre n'est pas obligatoire pour un greffon de type afterReturning : la 
methode handleNotifi cation pourrait tout aussi bien ne pas le declarer et AspectJ ne passerait 
alors pas le JointPoint (le greffon n'aurait alors aucune dependance vers Foutil de POA). 

Le reste de la definition de Faspect s'effectue dans le fichier de contexte Spring. Nous 
commencons par declarer le schema XML utilise pour la POA : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xml ns :xsi="http: //www.w3 . org/2001 /XMLSchema - i nstance" 
xmlns:aop=" http://www.spr ingframework.org/schema/aop" 
xsi :schemal_ocation=" 

http: //www. spri ngframework.org/schema/beans 

http: //www. spri ngf ramework. org/ schema /beans /spri ng- beans .xsd 

http://www.springframework.org/schema/aop 

http://www.springframework.org/schema/aop/spring-aop.xsd"> 

Le schema par defaut etant deja utilise, nous specifions un prefixe pour les tags de la POA. Par 
convention, ce prefixe est aop. 
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Comme pour la version Spring AOP pure, nous declarons le Bean correspondant au greffon. 
Sa configuration est identique a la precedente, au package pres : 

<bean id="notifier" 

cl a ss=" tudu. service. not ify.impl .ConsoleNotifier" /> 

<bean id="notifyAdvice" 

cl ass=" tudu. aspects .not i fy . aspect j .Not if ierAdvi ce "> 

<property name="notifier" ref="notifier" /> 
</bean> 

Nous definissons ensuite l'aspect grace aux balises dediees a la POA : 

<aop:config><— Q 

<aop: aspect ref-"notifyAdvice"><— Q 
<aop:pointcut id="coupe" expression-" 
execution(* tudu. servi ce. impl .UserManagerlmpl . createUser( . . ) ) "<— Q 
/> 

<aop: after -returning method="handl eNotifi cation" 
pointcut-ref="coupe" /><— Q 
</aop:aspect> 
</aop:config> 

Le tag aop:config encapsule les definitions d'aspects (Q). Un aspect est defini par le tag 
aop : aspect. L'attribut ref fait reference au greffon associe a l'aspect (Q). La coupe est definie 
par le tag aop : poi ncut, dont l'attribut expressi on permet de specifier sous forme d'expression 
reguliere (dans un format specifique d'AspectJ) la methode a intercepter (©). Ici, il s'agit 
d'intercepter toutes les executions de la methode createUser de UserManagerlmpl. Nous 
detaillons plus loin la syntaxe a respecter pour initialiser ce parametre. 

Le parametre id de la coupe permet de la nommer pour l'associer a un ou plusieurs greffons. 
Le tag aop: after- returning permet d'associer le greffon et la coupe (©). Le parametre 
method specifie la methode correspondant au greffon, et le parametre pointcut-ref la refe- 
rence a la coupe. 

Avec cette nouvelle definition de greffon et ces elements de configuration, la creation d'un 
utilisateur fait done l'objet d'une notification, sous la forme d'un message dans la console. 

Apres ces premiers pas dans la POA avec Spring, les sections suivantes detaillent les fonction- 
nalites dediees proposees par le framework. Nous commencerons par celles offertes par 
Spring AOP classique, e'est-a-dire sans support d'AspectJ (version 1.2 de Spring). Nous 
verrons ensuite le support d'AspectJ, qui a ete introduit a partir de la version 2.0 du 
framework. 



Utilisation de Spring AOP classique 

Spring supporte la POA depuis sa version 1.0. Ce support se presente sous la forme d'un 
framework 100 % Java implementant les notions de POA sous forme de Beans gerables par le 
conteneur leger. 
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Nous detaillons dans les sections qui suivent la facon dont les differentes notions introduites 
par la POA sont utilisables avec Spring AOP classique. 

Definition d'un aspect 

En POA, la notion d' aspect est F equivalent de celle d'objet en POO. Nous allons voir 
comment cette notion est implementee par Spring AOP. 

La definition d'un aspect avec Spring AOP passe par 1' implementation du greffon sous forme 
d'une classe Java implementant une certaine interface, selon le type de greffon 
(afterReturning, before, etc.), la definition de la coupe sous la forme d'un Bean et Fassem- 
blage des deux dans un advisor. 

Un advisor est un terme Spring faisant reference a la notion d' advice (que nous avons francise 
en greffon, plus parlant pour le lecteur). Spring AOP propose plusieurs types d' advisors, dont 
1' implementation de base est Defaul tPointcutAdvisor, que nous avons eu l'occasion d'utiliser 
dans notre exemple introductif. 

Cette implementation de base fixe le principe fondamental de F advisor, qui consiste a associer 
une coupe et un greffon. La definition de Faspect passe done par la definition de trois Beans : 
le greffon, la coupe et F advisor. Ce dernier se voit injecter le greffon et la coupe. 

Spring AOP classique propose differents moyens de definir une coupe. Afin de diminuer le 
nombre de lignes de configuration, il existe une classe d' advisor pour chacun de ces moyens. 
Les differentes classes d' advisor permettent de parameter directement la coupe plutot que de 
la specifier sous forme de Bean specifique, comme nous Favons fait dans l'exemple introductif. 
Cela permet une configuration plus concise. 

Nous verrons Futilisation des differents advisors disponibles dans Spring AOP classiques lors 
de notre etude des coupes, car ces deux notions sont tes liees. 

Portee des aspects 

Dans Spring AOP classique, la portee des aspects est limitee par rapport a des outils de POA 
supportant Fensemble des concepts de ce nouveau paradigme. Spring AOP classique se limite 
a intercepter F execution de methodes des Beans geres par le conteneur leger. II n'est done pas 
possible d'intercepter une classe de F application qui ne serait pas definie sous forme de Bean. 
Cette limitation n'est toutefois guere penalisante, car Fessentiel des developpements impli- 
quant des aspects repose sur des coupes de ce type. 

Par defaut, les aspects de Spring AOP sont des singletons, e'est-a-dire qu'ils sont partages par 
Fensemble des classes et des methodes qu'ils interceptent. II est possible de changer ce mode 
d'instanciation en utilisant la propriete singleton (a ne pas confondre avec le paramete 
singleton du tag bean) des proxy specifiques, que nous abordons plus loin. 

Les coupes 

Dans Spring AOP classique, la notion de coupe est formalisee sous la forme de Finterface 
Pointcut, definie dans le package org.springframework.aop. Cette interface specifie deux 
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methodes, getClassFilter et getMethodMatcher, permettant de savoir quelles sont les classes 
et methodes concernees par la coupe. 

Cette interface dispose de plusieurs implementations, utilisables directement pour definir les 
coupes de nos aspects. Avec Spring AOP classique, il existe trois facons de definir des 
coupes : 

• par la designation directe des methodes a intercepter ; 

• par la designation des methodes a intercepter via des expressions regulieres ; 

• par la syntaxe AspectJ. 

Chacune des facons correspond a une implementation de Pointcut. Comme indique prece- 
demment, Spring introduit la notion d' advisor, representee par la classe de base 
DefaultPointcutAdvisor, qui agrege un greffon et une coupe. A chacune des implementations 
de Poincut correspond un advisor, qui permet de definir directement la coupe et d'injecter le 
greffon, plutot que de definir la coupe dans un Bean separe et de l'injecter dans un 
Def aul tPointcutAdvi sor. 

Nous allons privilegier dans nos exemples l'utilisation des advisors correspondant aux imple- 
mentations de Pointcut, car il s'agit de la maniere la plus concise et la plus claire. 

NameMatchMethodPointcutAdvisor 

NameMatchMethodPointcutAdvisor permet de definir une coupe a partir du nom de methode a 
intercepter. C'est le principe que nous avons utilise pour notre exemple introductif. 

Nous pouvons revoir la definition de la coupe de l'exemple en utilisant directement un 
NameMatchMethodPointcutAdvisor plutot que de passer par la coupe (advice) corres- 
pondante : 

<bean id="notifierAdvisor" class=" 

org.springf ramework.aop. support. NameMatchMethodPointcutAdvisor "> 

<property name="advice" ref="notifyAdvice" /> 
<property name="mappedName" val ue="createUser" /> 

</bean> 

La coupe est directement definie en tant que propriete, via mappedName. La propriete 
mappedNames permet de definir un ensemble de methodes, separees par des virgules. 

RegexpMethodPointcutAdvisor 

RegexpMethodPointcutAdvisor permet d'utiliser des expressions regulieres pour definir les 
noms des methodes a intercepter. II est done beaucoup plus puissant que F advisor precedent, 
pour lequel la liste complete des methodes doit etre fournie, ce qui peut devenir rapidement 
rebarbatif. S'il represente une avancee, il ne s'agit cependant par d'une solution optimale : les 
expressions regulieres permettent de definir des noms de methodes facilement, mais elles ne 
permettent pas de filtrer sur les types de retour ou les parametres d'entree des methodes a 
intercepter. 
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Cet advisor dispose de deux proprietes, pattern et patterns. La premiere doit etre initialisee 
quand une seule expression reguliere est necessaire pour specifier la coupe. La seconde est un 
tableau de chaines de caracteres a utiliser lorsque plusieurs expressions regulieres sont neces- 
s aires. 

En reprenant notre exemple, nous utilisons cet advisor de la maniere suivante : 

<bean id="notifierAdvisor" class=" 
org.springf ramework.aop. support. RegexpMethodPoint cut Advisor "> 

<property name="advi ce" ref="notifyAdvice" /> 
<property name="pattern" 
value=".*UserManagerImpl .createUser.*" /> 

</bean> 

Aspect J Expression Poi ntcut Advisor 

Cet advisor permet d'utiliser la syntaxe AspectJ pour definir les coupes d'un aspect. De tous 
les advisors vus jusqu'ici, il est le plus puissant et le plus souple, car la syntaxe AspectJ est 
faite pour definir des coupes. Cependant, il a un statut specifique : s'il s'integre completement 
dans le cadre de Spring AOP classique (done de Spring 1.2), il n'est disponible que depuis 
Spring 2.0. 

Voici comment utiliser 1'AspectJExpressionPointcutAdvisor : 
<bean id="notifierAdvisor" class=" 

org.springf ramework. aop. aspect j .AspectJ Express ion Poi ntcutAdvi sor "> 

<property name="advi ce" ref="notifyAdvice" /> 
<property name="expression" value-" 
execution(* tudu.se rvi ce. impl .UserManagerlmpl . createUser ( . . ) ) " 

/> 
</bean> 

De par son introduction dans Spring 2.0, cet advisor ne peut etre utilise que dans un contexte 
approprie. Une application Spring 1.2 commencant a migrer vers Spring 2.x peut, par exem- 
ple, l'utiliser pour definir ces coupes dans le cadre de Spring AOP classique avant de migrer 
totalement vers le support AspectJ. 



Les greffons 

Les greffons sont specifies sous forme de Beans. Avec Spring AOP classique, ces Beans 
doivent implementer des interfaces specifiques. Afin de permettre aux greffons de realiser des 
traitements en fonction de leur contexte d' execution, ces interfaces leur permettent d'acceder 
a des informations detaillees sur les methodes interceptees. 

Spring AOP supporte nativement quatre types de greffons. Chacun d'eux est formalise par une 
interface specifique. Cette interface specifie une methode devant declencher le traitement du 
greffon. Cette methode contient plusieurs parametres, fournissant des informations sur F inter- 
ception. 
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Les greffons de type around 

Les greffons de type around doivent implementer l'interface Methodlnterceptor du package 
org. aopalliance. intercept. Cette interface specifie la methode invoke, dont la signature est 
la suivante : 

public Object invoke(MethodInvocation invocation) throws Throwable 

Le parametre invocation permet d'acceder aux informations concernant la methode intercep- 
tee (nom, classe d'appartenance, arguments, etc.). Ce parametre dispose d'une methode 
proceed, a appeler pour declencher l'execution de la methode interceptee. 

Nous pouvons reecrire le greffon de notre exemple introductif en utilisant cette interface : 
package tudu. aspects. notify. classic; 

import org.aopall iance. intercept. Met hod Interceptor; 
import org. a opal 1 iance. intercept. Met hod In vocation; 

import tudu. service. notify .Not if ier; 

import tudu. service. notify. impl .StringMessage; 

public class NotifierAroundAdvice implements Methodlnterceptor { 
private Notifier notifier; 

public void setNotifier( Notifier notifier) { 
this. notifier = notifier; 

} 

public Object invoke(MethodInvocation invocation) 

throws Throwable { 

Object ret = invocation. proceedO ; 
notifier. notify (new StringMessaget 

"appel de "+invocation.getMethod( ) .getName( ) 

)); 

return ret; 

} 

} 

Les greffons de type before 

Les greffons de type before doivent implementer l'interface MethodBeforeAdvice du package 
org.springframework.aop. Cette interface specifie la methode before, dont la signature est la 
suivante : 

public void before(Method method, Object[] args. Object target) 
throws Throwable 
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Le parametre method permet d'acceder aux informations concernant la methode interceptee. 
Les arguments de la methode sont contenus dans le parametre args. Le parametre target 
contient la reference a l'objet possedant la methode interceptee. 

Nous pouvons reecrire le greffon de notre exemple introductif en utilisant cette interface : 
package tudu. aspects. notify. classic; 

import java . 1 ang. ref 1 ect .Method ; 
import org.springf ramework.aop. Met hodBeforeAd vice; 

import tudu. service. notify. Not ifier; 
import tudu. service. notify. impl .StringMessage; 

public class NotifierBeforeAdvice implements MethodBeforeAdvi ce { 



private Notifier notifier; 



public void setNotifier(Notifier notifier) { 
this. notifier = notifier; 

} 



public void before(Method method, Object[] args, Object target) 

throws Throwable { 

notifier. notify (new StringMessage( 
"appel de "+method.getName() 

)); 

} 

} 

En utilisant ce type de greffon, la generation s'effectue avant F execution de la methode inter- 
ceptee, et non plus apres, comme dans l'exemple introductif. 

Les g ref tons de type after returning 

Les greffons de type after returning doivent implementer Finterface AfterReturningAdvice 
du package org.springframework.aop. Cette interface specifie la methode afterReturning, 
dont la signature est la suivante : 

public void afterReturning(Object returnValue, Method method, 

Object[] args, Object target) throws Throwable 

Le parametre returnVal ue donne acces a la valeur de retour qui a ete renvoyee par la methode 
interceptee. Les autres parametres ont la meme signification que ceux des greffons de type 
before. 

C'est ce type de greffon que nous utilisons dans l'exemple introductif : 

package tudu. aspects. notify. classic; 
import j a va.l ang. reflect. Met hod; 

import org.springf ramework.aop. AfterReturningAdvice; 
import tudu. service. notify .Notifier; 
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import tudu. service. notify. imp! .StringMessage; 

public class NotifierAdvice implements AfterReturningAdvice { 

private Notifier notifier; 

public void setNotifier( Notifier notifier) { 
this. notifier = notifier; 

) 



public void afterReturning(Object returnValue, Method method, 
Object[] args, Object target) throws Throwable { 

notifier. notify( 

new StringMessageC'appel de "+method .getName( ) ) 

); 



Les greffons de type after throwing 

Les greffons de type after throwing doivent implementer Finterface ThrowsAdvice du 
package org.springframework.aop. Contrairement aux interfaces precedentes, celle-ci ne 
specifie pas de methode. Spring AOP utilise ici la reflexivite pour detecter une methode sous 
la forme suivante : 

public void afterThrowing(Method method, Object[] args. 

Object target, Throwable exception) 

L' utilisation de la reflexivite permet de remplacer le type du dernier parametre exception par 
n'importe quelle classe ou interface derivant de Throwable. II s'agit generalement du type de 
Fexception generee par les methodes interceptees contenues dans exception. 

L' implementation suivante de notre greffon declenche Fevenement uniquement si Fune des 
methodes de UserManagerlmpl genere une exception : 

package tudu. aspects. notify .classic; 

import j a va.lang. reflect. Met hod; 
import org .springf ramework. aop. Throws Advice ; 

import tudu. service. notify .Notifier; 
import tudu. service. notify. impl .StringMessage; 

public class NotifierAfterThrowingAdvice implements ThrowsAdvice { 
private Notifier notifier; 

public void setNotifier( Notifier notifier) { 
this. notifier = notifier; 

} 
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public void afterThrowing(Method method, Object[] args, 
Object target, Exception ex) { 

notifier. notify (new StringMessage( 

"exception lancee dans la methode "+method.getName( ) 

)); 

} 



Utilisation de Spring AOP avec AspectJ 

Depuis la version 2.0 de Spring, le support de la POA par le framework progresse de maniere 
significative grace au support natif d'une partie des fonctionnalites d' AspectJ. 

II s'agit essentiellement du support du langage de specification de coupe propre a AspectJ, 
ainsi que des annotations Java 5, qui permettent de definir un aspect a partir d'une simple 
classe Java. 

Fondamentalement, les capacites du framework sont les memes. Les progres se situent dans le 
moindre effort de programmation necessaire et dans une plus grande independance du code des 
aspects vis-a-vis de Spring AOP, puisqu'il n'y a plus d' interfaces du framework a implemented 



Definition d'un aspect 

Le support d' AspectJ permet de definir un aspect selon deux formats. Le premier est fonde sur 
XML, et le second sur les annotations Java 5. Les sections suivantes detaillent ces deux 
formats. 

Le format XML 

Comme indique dans l'exemple introductif, la definition d'un aspect sous forme XML 
s'effectue via le tag aop: aspect. La notion d'aspect est associee a un Bean devant contenir 
l'ensemble des greffons utilises par l'aspect via le parametre ref du tag. Chaque greffon est 
materialise sous la forme d'une methode. 

La definition de la coupe s'effectue directement dans le fichier de configuration, sans necessi- 
ter la creation d'un Bean specifique. La definition de la coupe s'effectue via une expression 
reguliere specifique d' AspectJ, que nous decrivons a la section dediee aux coupes. 

Dans notre exemple introductif, la coupe est definie separement de F association avec le greffon 
effectuee par le tag aop: advice. Elle est alors referencee par le parametre pointcut-ref. Lavantage 
de cette solution est que cette forme permet de reutiliser cette coupe avec un autre greffon. 

Si cela n'est pas necessaire, il est possible de definir la coupe directement dans le tag, avec le 
parametre pointcut : 

<aop:config> 

<aop: aspect ref-"noti fyAdvi ce"> 
<a op: after -returning 
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method="handl eNotif i cation" 
pointcut=" 

execution(* tudu. service. impl .UserManagerlmpl .createUser( . . ))" 

/> 

</aop:aspect> 
</aop:config> 

Utilisation des annotations Java 5 

Les annotations Java 5 permettent de definir un aspect directement a partir du Bean contenant 
les greffons. 

Ainsi, nous pouvons configurer notre aspect en annotant directement la classe 
NotifierAdvice : 

package tudu. aspects. notify. aspect j ; 

import org.aspectj .1 ang. Join Point ; 

import org.aspectj .1 ang.annotation.AfterReturning; 

import org.aspectj .1 ang. annotation. Aspect; 

import tudu. service. notify .Not if ier; 

import tudu. service. notify. impl .StringMessage; 

@Aspect 

public class NotifierAdvice { 

public void setNotifier( Notifier notifier) { 
this.notifier = notifier; 

} 

private Notifier notifier; 

@AfterReturning( 
"execution(* tudu. service. impl .UserManagerlmpl .createLlser( . . ) )" 



Le marquage de la classe comme etant un aspect est assure par Fannotation ©Aspect. La defi- 
nition du greffon et de son type ainsi que de la coupe associee est effectuee par Fannotation 
©AfterReturning. II existe une annotation par type de greffon, comme nous le verrons a la 
section dediee a ces derniers. 




public void handleNotification(JoinPoint jp) { 
notifier. notify (new StringMessage( 

"appel de "+jp.getSignature( ) .getName( ) 

)); 



) 



Meme si les annotations prennent en charge l'ensemble de la definition de l'aspect, il reste 
necessaire d'avertir le conteneur leger de la presence d' aspects definis de la sorte. 
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II faut utiliser le tag aop:aspectj-autoproxy pour les tisser et declarer les aspects sous forme 
de Bean : 

<aop:aspectj-autoproxy /> 

<bean id="notifier" 

cl ass="tudu. service. not ify.impl .Consol eNoti f i er" /> 

<bean id="notifyAdvice" 
cl ass=" tudu. aspects. notify .aspect j . NotifierAdvice"> 
<property name="notifier" ref="notifier" /> 
</bean> 

Portee des aspects 

Les aspects definis avec le support d' AspectJ sont des singletons par defaut. II est possible de 
controler leur instanciation s'ils sont definis en utilisant les annotations. Seuls les Beans geres 
par le conteneur leger peuvent etre tisses avec les aspects. 

L' annotation ©Aspect accepte les parametres perthis et pertarget a cette fin. Leur utilisation 
assez complexe depassant le perimetre de notre introduction a la POA, nous ne l'abordons pas 
dans le cadre de cet ouvrage. 



Les coupes 

La specification des coupes en utilisant le support d'AspectJ ne necessite pas l'instanciation 
de Beans specifiques, contrairement a Fapproche precedente. 

Les coupes sont specifiees sous forme d'expressions regulieres selon un format propre a AspectJ. 

Le support d'AspectJ propose par Spring AOP ne comprend qu'un seul type de point de jonc- 
tion, executi on, qui intercepte les executions de methodes. A ce point de jonction est associee 
une expression reguliere specifiant les methodes a intercepter. 

AspectJ fournit un mecanisme permettant, a Faide de symboles specifiques, de creer des 
expressions englobant plusieurs methodes. Ces symboles sont appeles des wildcards. Le 
mecanisme de wildcard fournit une syntaxe riche, permettant de decrire de nombreuses 
coupes. En contrepartie, cette richesse peut conduire a des expressions de coupe complexes et 
subtiles. Nous decrivons ici les usages les plus courants des wildcards. 

Noms de methodes et de classes 

Le symbole * peut etre utilise pour remplacer des noms de methodes ou de classes. Nous 
verrons qu'il peut l'etre egalement pour des signatures de methodes et des noms de packages. 

En ce qui concerne les methodes, le symbole * designe tout ou partie des methodes d'une 
classe ou d'une interface. 

L'expression suivante designe l'execution de toutes les methodes publiques de la classe 
UserManagerlmpl prenant en parametre une chaine de caracteres et retournant void : 

executi on (publ ic void tudu. service. impl .UserManagerlmpl .*(String)) 



Les fondations de Spring 

Partie I 



Le symbole * peut etre combine avec des caracteres afin de designer, par exemple, toutes les 
methodes qui contiennent la sous-chaine Manager dans leur nom. Dans ce cas, l'expression 
s'ecrit *Manager*. 

Le symbole * peut aussi etre utilise pour les noms de classes ou d'interfaces. L'expression 
suivante designe 1' execution de toutes les methodes publiques de toutes les classes ou interfa- 
ces du package tudu. service. impl, qui prennent en parametre une String et qui retournent 
void : 

execution(public void tudu. service. impl .*.*(String)) 

Signatures de methodes 

Au-dela des noms, les parametres, types de retour et attributs de visibilite (publ i c, protected, 
pri vate) jouent un role dans 1' identification des methodes. AspectJ offre la possibilite de les 
inclure dans les expressions de coupes. 

Les parametres de methodes peuvent etre omis grace au symbole « . . ». L'expression 
suivante designe l'execution de toutes les methodes publiques retournant void de la classe 
UserManagerlmpl , quel que soit le profil de leurs parametres : 

execution (publ i c void tudu.servi ce. impl .UserManagerlmpl .*(..)) 

Le type de retour et la visibilite d'une methode peuvent quant a eux etre omis a l'aide du 
symbole *. 

L'expression suivante designe l'execution de toutes les methodes de la classe UserMana- 
gerlmpl, quels que soient leurs parametres, type de retour et visibilite : 

execution(* tudu.servi ce. impl .UserManagerlmpl .*(..)) 

Noms de packages 

Les noms de packages peuvent etre remplaces par le symbole « . . ». 

Par exemple, l'expression suivante designe l'execution de toutes les methodes de toutes les 
classes contenant User dans n'importe quel package de la hierarchie tudu, quel que soit le 
niveau de sous-package de cette hierarchie : 

execution(* tudu. .User*. *(.. )) 

Combinaisons de coupes 

II est possible avec AspectJ de specifier des coupes composites en utilisant les operateurs and 
(intersection), or (union) et not (exclusion). 

Nous pouvons ainsi definir une coupe sur toutes les methodes de la classe UserManagerlmpl, 
sauf la methode disableUser : 

execution(* tudu. service. impl .UserManagerlmpl .*(.. )) and not 
execution(* tudu.servi ce.impl .UserManagerlmpl .di sabl eUser( . . ) ) 
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Tester les coupes 

La syntaxe AspectJ s'averant difficile a maitriser, il peut etre interessant de tester les expres- 
sions que Ton cree. Ces tests peuvent etre inclus dans les tests unitaires de non-regression 
automatises d'une application, car la bonne configuration de la POA fait aussi partie des tests 
d' integration. 

Voici par exemple comment tester qu'une expression AspectJ correspond ou pas a certaines 
methodes d'une classe : 

package t udu. aspects. notify. a spectj ; 



import java.lang. reflect. Method; 

import org. junit. Assert; 

import org. junit. Test; 

import org. springf ramework.aop. aspect j .AspectJ Exp ressi on Pointcut; 



import tudu. service. impl .UserManagerlmpl ; 

public class AspectJSyntaxTest { 

©Test public void methodAndCl assName( ) throws Exception { 
AspectJExpressionPointcut pointcut = new 

AspectJExpressionPointcut( ) ;<— O 
pointcut. set Exp ressi on ( 

"execution(publ ic void "+ 

"tudu. service. impl .UserManagerlmpl . *(String) )" 
);<^0 

Method enabl eUserMethod = UserManagerlmpl .class. getMethodt 
"enabl eUser" , String. class 

); 

Method di sabl eUserMethod = UserManagerlmpl .class. getMethod( 
"di sabl eUser" , String. class 

); 

Method findUserMethod = UserManagerlmpl .class. getMethod( 

"findUser", String. class 
);<^© 

Assert . as sertTrue( pointcut .matches ( 

enabl eUserMethod .UserManagerlmpl . cl ass 

)); 

Assert . as sertTrue( pointcut .matches ( 

di sabl eUserMethod .UserManagerlmpl .class 

)); 

Assert . assert Fa 1 se (pointcut .matches ( 

f i ndUserMet hod .UserManagerlmpl . cl ass 
));<^© 

} 

} 



Les fondations de Spring 

Partie I 



L'exemple montre un test unitaire JUnit 4, dont l'unique methode de test methodAnd-Cl assName 
cree en premier lieu une coupe fondee sur AspectJ (AspectJExpressionPoincut) au repere Q. 
L' expression AspectJ est definie au repere Q et designe Fensemble des methodes de la classe 
UserManagerlmpl qui acceptent en parametre une Stri ng et qui retournent voi d. Suivent trois defi- 
nitions de java.lang. reflect. Method faisant reference a des methodes de UserManagerlmpl (Qi). 
Enfin viennent les verifications (Q) : les deux premieres passent le test, car les methodes 
enabl eUser et di sabl eUser correspondent parfaitement a la definition de la coupe. La methode 
f i ndUser ne correspond pas a la coupe, car elle ne retourne pas voi d. 

Lecriture de ce genre de test est interessante dans les cas ou la POA implemente des fonction- 
nalites critiques d'une application (transactions, gestion des ressources, securite). En effet, 
une erreur minime dans 1' expression ou une modification du code (changement de nom de 
package, ajout d'un parametre dans une methode) peut rendre inoperants des aspects. 

Pour plus d' informations sur les tests unitaires en general, voir le chapitre 6. 



Les greffons 

Avec le support d' AspectJ, les greffons sont simples a definir, car ils ne supposent pas F imple- 
mentation d'interfaces specifiques. Cette definition peut s'effectuer de deux manieres : en 
utilisant le fichier de configuration XML du conteneur leger ou en utilisant les annotations. 

Rappelons que, pour utiliser les annotations, il est necessaire de disposer d'une JVM version 5 
au minimum. A l'instar des interfaces de Spring AOP classique, les greffons AspectJ ont la 
capacite d'acceder a des informations sur la methode intercepted selon deux methodes, que 
nous abordons dans cette section. 

Lorsque le fichier de configuration est utilise pour creer les aspects de F application, la defini- 
tion du type de greffon se fait via un tag approprie du schema XML de la POA. II existe done 
un tag pour chacun des types de greffons: aop:before, aop:after, aop: around, 
aop:afterReturning et aop:afterThrowing. 

Pour le type around, il est necessaire de modifier la signature du greffon afin qu'il recoive en 
parametre un objet de type ProceedingJoinPoint, qui donne acces a la methode proceed. Par 
ailleurs, le greffon doit pouvoir transmettre les exceptions et les valeurs de retour susceptibles 
d'etre generees par proceed. 

Avec la configuration XML et pour chacun des types de greffon, il est necessaire de preciser 
la methode correspondant au greffon, avec Pattribut method : 

<aop:config> 
<aop : aspect ref-"noti fyAdvi ce" > 

<aop:pointcut id="coupe" expression-" 
execution(* tudu. service. impl .UserManagerlmpl . createUser( . . ) ) " 

/> 

<aop: after -returning method="handleNotifi cation" 

pointcut-ref-"coupe" /> 
</aop:aspect> 
</aop:config> 
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Lorsque la definition des aspects s'effectue par annotation, nous disposons d'une annotation 
par type de greffon. 

En plus de @AfterReturning, que nous avons deja rencontre, nous disposons de ©Before, 
©After, ©Around et ©AfterThrowing, qui fonctionnent tous selon le meme principe. 

A l'instar de la configuration XML, les greffons de type around doivent etre modifies pour 
prendre en parametre l'objet donnant acces a la methode proceed. 

Notons que le support d'AspecJ propose le type after, non specifie sous forme d'interface 
par Spring AOP classique. Ce type est F equivalent de afterReturning et de afterThrowing 
reunis. II est appele quel que soit le resultat de F execution de la methode interceptee (valeur 
de retour ou exception). 

Introspection et typage des coupes 

Les greffons d'AspecJ ont la possibility d'acceder aux informations concemant la methode 
interceptee. Cet acces peut se faire de deux manieres : en utilisant un objet de type JoinPoint 
(dont le type ProceedingJoinPoint utilise par les greffons de type around derive), permettant 
1' introspection de la methode interceptee, ou en typant les coupes. 

Pour pouvoir realiser une introspection de la methode interceptee, il est necessaire de specifier 
comme premier parametre (obligatoire) un argument de type JoinPoint (ou derive). Cette 
modification est valable en configuration XML et avec les annotations. 

Notre exemple introductif de notification utilisait le JoinPoint pour recuperer le nom de la 
methode executee : 

package t udu. aspects. notify. a spectj ; 

import org. aspect j . 1 ang. JoinPoint ; 

import tudu. service. notify .Notifier; 

import tudu. service. notify. impl .StringMessage; 

public class NotifierAdvice { 

private Notifier notifier; 

public void setNotifier(Notifier notifier) { 
this, notifier = notifier; 

} 

public void handleNotification( JoinPoint jp) { 
notifier. notify (new Stri ngMessage( 

"appel de "+ jp.getSignature( ) .getName( ) 

)); 

} 

} 

La methode getSi gnature de la classe Joi nPoi nt permet d' avoir des informations sur la signature 
de la methode (nom, portee, etc.) sous la forme d'un objet de type org. aspect j .1 ang. Signature. 
Dans notre exemple, nous utilisons la methode getName pour obtenir le nom de la methode. 
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La classe JoinPoint possede d'autres methodes, souvent utiles pour les greffons : 

• getThis : renvoie la reference vers le proxy utilise pour Finterception (voir la section consa- 
cree au tissage ). 

• getTarget : renvoie la reference vers Fobjet auquel appartient la methode interceptee. 

• getArgs : renvoie la liste des arguments passes en parametres a la methode interceptee sous 
forme d'un tableau d'objets. 

Typage de la coupe 

La recuperation des informations sur la methode interceptee peut s'effectuer de maniere forte - 
ment typee (contrairement a 1' introspection, que nous venons de voir). Pour cela, nous 
pouvons associer ces informations a des parametres formels du greffon. 

Ainsi, les resultats de getThis, getTarget et getArgs peuvent etre directement accessibles 
depuis des parametres du greffon. Pour la derniere methode, il est possible de specifier une 
liste fixe et typee d' arguments, evitant ainsi d'utiliser la reflexivite dans le code du greffon. 

Les greffons de types afterReturning et afterThrowing peuvent avoir acces respectivement a 
la valeur de retour ou a l'exception renvoyee par la methode interceptee. 

this et target 

La specification des parametres this et target s'effectue a deux niveaux : dans la coupe, en 
complement de l'expression reguliere associee au point de jonction executi on, et au niveau du 
greffon, sous la forme d'un parametre. 

Si nous voulons recuperer dans le greffon de notre exemple une reference a l'objet dont la 
methode a ete interceptee, nous devons modifier notre coupe de la maniere suivante : 

executi on (* tudu.servi ce. impl .UserManagerlmpl .createLlser( . . ) ) 
and target(userManager) 

Le nom userManager donne ici doit correspondre au nom du parametre correspondant dans le 
greffon. 

Notre greffon peut s'ecrire maintenant de la maniere suivante : 
(...) 

import tudu. service. UserManager; 
(...) 

public void handleNotification( 

JoinPoint jp, UserManager userManager) { 
notifier. notify (new StringMessage( 
"appel de "+jp.getSignature( ) .getName( ) 

)); 

} 

Lutilisation de this est identique a celle de target. Le type de parametre doit etre Object, car 
il s'agit d'une reference a un proxy dynamique dont la classe ne peut etre connue a Favance. 



Spring AOP 

Chapitre 5 



args 

Comme avec this et target, les arguments a recuperer doivent etre specifies dans la coupe a 
l'aide du parametre args et au niveau des arguments du greffon. 

Si nous voulons recuperer l'utilisateur a creer, nous devons specifier la coupe de la maniere suivante : 

execution(* tudu. service. impl .UserManagerlmpl .*(..)) 
and args(user) 

Notre greffon peut s'ecrire maintenant de la maniere suivante : 
(...) 

import tudu. domain. model .User; 
(...) 

public void handleNotification( 
JoinPoint jp, User user) { 
notifier. notify (new StringMessage( 

"appel de "+jp.getSignature( ) .getName( ) 

)); 

} 

Le fait de specifier de maniere formelle les arguments recuperes par le greffon exclut d' office 
les methodes dont les arguments ne correspondent pas a ceux attendus. Ainsi, la methode 
findUser ne serait pas interceptee, meme si elle correspond a la coupe, car son unique argument 
est de type String et pas User. 

II est possible de specifier une liste d' arguments dans le parametre args en les separant par des 
virgules. Les symboles * et . . sont autorises pour specifier des arguments dont le type est 
indefini et qui ne doivent pas etre associes avec les arguments du greffon. 

returning 

Les greffons de type af terReturni ng peuvent acceder a la valeur de retour de la methode inter- 
ceptee. Pour ce faire, il est necessaire de declarer un argument du greffon comme etant destine 
a recevoir cette information. 

Pour la configuration XML, il faut utiliser le parametre returning dans le tag aop: after- 
Returning en lui fournissant le nom de l'argument du greffon : 

<aop: after -returning 

method="handl eNoti f i cation" 
pointcut=" 

executi on(* tudu. servi ce. impl . UserManagerlmpl . getCu r rent Use r( . . ) ) " 
returning="theCurrentUser" 

/> 

Pour les annotations, il faut utiliser le parametre returning de @Af terReturni ng : 
@AfterReturning( 
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pointcut=" 

execution(* tudu.servi ce.impl .UserManagerlmpl . getCurrentUser( ..))", 
return ing="theCurrentUser" 

) 

Dans les deux cas, le greffon devient le suivant : 
(...) 

import tudu. domain. model .User; 
(...) 

public void handleNotification( 

JoinPoint jp.User theCurrentUser ) { 
notifier. notify (new StringMessage( 

"appel de "+jp.getSignature( ) .getName( ) 

)); 

} 

throwing 

Les greffons de type afterThrowing doivent pouvoir acceder a Fexception generee par la 
methode interceptee. La encore, il est possible pour ce faire de declarer un argument du greffon 
comme etant destine a recevoir cette information. 

Pour la configuration XML, il faut utiliser le parametre throwing dans le tag 
aop: afterThrowing en lui fournissant le nom de Fargument du greffon : 

<aop: after -throwing 

method="handleNotifi cation" 
pointcut=" 

execution(* tudu.servi ce.impl .UserManagerlmpl .createUser( . . ) )" 
throwing-" exception" 

/> 

Pour les annotations, il faut utiliser le parametre throwing de ©AfterThrowing : 

@AfterThrowing( 
pointcut=" 

execution(* tudu.servi ce. impl .UserManagerlmpl .createUser( ..))", 
throwing-" except ion" 

) 

Dans les deux cas, le greffon devient le suivant : 
(...) 

public void handleNotification( 

JoinPoint jp, Throwable exception) { 

notifier. notify (new StringMessage( 

"appel de "+jp.getSignature( ) .getName( ) 

)); 

} 
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L' exception en parametre d'un greffon de type afterThrowing peut etre d'un type derivant 
de Throwable. Nous utilisons ici Throwable, mais il serait possible d'utiliser 
UserAlreadyExistsException, la methode createUser etant susceptible de renvoyer ce type 
d' exception. 



Le mecanisme d'introduction 

En POA, F introduction permet d'etendre le comportement d'une classe en modifiant sa struc- 
ture. Avec Spring et son support pour la POA, l'introduction consiste a faire implementer une 
interface a un Bean declare dans un contexte Spring. 

Nous n'etudierons ici que le mecanisme d'introduction du support AspectJ de Spring, pas 
celui de Spring AOP classique. 

Nous allons voir en premier lieu une introduction avec la configuration XML : 

<aop: aspect ref="noti fyAdvice"> 
<aop:decl a re -pa rents 

types -matchi ng="tudu. service. impl .UserManagerlmpl "<— Q 

def ault- impl-" tudu. service. notify. impl . ConsoleNotif ier"<— Q 

implement- interface-" tudu. service.notify.Notifier"<— Q 

/> 

</aop:aspect> 

L'attribut types -matchi ng precise les classes devant faire Fobjet de l'introduction (0). L'attri- 
but default-impl indique 1' implementation par defaut a utiliser (Q). Enfin, implement- 
interface indique l'interface qui est implementee (©). 

Tout objet du contexte Spring de type UserManagerlmpl va done implementer l'interface 
Notifier, en utilisant ConsoleNotifier comme implementation. II est done possible d'utiliser 
le UserManager comme Notifier dans l'aspect de notification : 

<bean id="notifyAdvice" class=" 

t udu. aspects. notify. aspect j. Notifier Ad vice"> 
<property name="notifier" ref-"userManager" /> 
</bean> 



<aop:config> 

<aop: aspect ref="noti fyAdvice"> 
<aop:decl a re -pa rents 

ty pes -ma tching="t udu. service. impl .UserManagerlmpl " 
implement-interface="tudu. service. notify. Notifier" 
default-impl="tudu. service. notify .impl . ConsoleNotif ier"/> 
<a op: after -returning 

method="handl eNotif i cation" 
poi ntcut-" 

execution(* tudu.servi ce. impl .UserManagerlmpl .createUser( . . ) )" 
/> 

</aop:aspect> 
</aop:config> 
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Le mecanisme d' introduction par annotation repose sur l'annotation @Decl areParents, qui 
prend deux parametres : val ue, qui designe la classe cible a etendre, et def aul tlmpl , qui speci- 
fic la classe foumissant F implementation de F introduction. Cette classe doit bien entendu 
implementer Finterface qui est introduite dans la classe cible. La specification de cette inter- 
face est fournie par Fattribut statique auquel s'applique l'annotation @Decl areParents. 

Si nous desirons etendre les fonctionnalites de la classe UserManagerlmpl du package 
tudu. service. impl afin qu'elle implemente Finterface Notifier, nous pouvons specifier 
F aspect suivant : 

package tudu. aspects. notify. aspect j ; 

import org.aspectj . lang. annotation. Aspect; 

import org. aspect j .1 ang. annotati on. Decl areParents ; 

i mport tudu . servi ce . noti fy . Noti f i er ; 

import tudu. service. notify. impl .ConsoleNotifier; 

©Aspect 

public class Notifierlntroduction { 

@Decl areParents( 

value="tudu. service. impl .UserManagerlmpl " ,<— © 
def aul tlmpl =Consol eNotif ier . cl ass<— Q 

) 

public static Notifier mixin;<— Q 

} 

Le parametre value de l'annotation contient une expression AspectJ qui indique quelles 
classes doivent faire Fobjet de Fintroduction (Q). Dans notre exemple, il s'agit seulement de 
la classe UserManagerlmpl . Le parametre def aul tlmpl indique F implementation a utiliser (Q). 
Linterface implementee (introduite) est precisee par le type de la propriete mixin (©). 
II s'agit dans notre cas de Notifier. 

Pour que Fintroduction soit effective, il est necessaire de declarer Notifierlntroduction sous 
forme de Bean et d'utiliser le tag aop: aspectj -autoproxy pour que le tissage s'effectue : 

<aop: aspectj -autoproxy /> 

<bean cl ass=" tudu. aspects. notify .aspectj .Notifierlntroduction" /> 

Le UserManager va maintenant implementer Finterface Notifier, il peut done etre utilise dans 
F aspect de notification : 

<bean id-"notifyAdvice" class=" 

tudu. aspects. notify .aspectj .NotifierAdvice"> 
<property name="notifier" ref="userManager" /> 
</bean> 

Dans le cas de la configuration XML comme dans celui des annotations, le UserManager effectue 
lui-meme ses notifications. 
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Le tissage des aspects 

Le tissage des aspects avec Spring AOP et son support d' AspectJ s'effectue grace a la creation 
dynamique de proxy pour les Beans dont les methodes doivent etre interceptees. Les utilisa- 
teurs de ces methodes obtiennent ainsi une reference a ces proxy (dont les methodes reprodui- 
sent rigoureusement celles des Beans qu'ils encapsulent), et non une reference directe aux 
Beans tisses. 

La generation de ces proxy est controlee au niveau du fichier de configuration du conteneur 
leger. Cette generation peut etre automatique pour les besoins courants ou specifique pour les 
besoins plus complexes. 

Les proxy automatiques 

Avec AspectJ, le tissage est uniquement automatique. Le seul controle dont dispose le deve- 
loppeur est de tisser ou non les aspects abase d'annotations via le tag aop: aspect j-autoproxy. 
Cette section concerne done principalement Spring AOP classique. 

Dans notre exemple introductif, nous avons utilise le mecanisme de proxy automatique afin de 
simphfier notre configuration. Spring AOP classique propose des modes de tissage automatique 
materialises par des Beans specifiques a instancier. 

Le mode le plus simple est celui utilise dans notre exemple. II utilise la classe 
DefaultAdvisorAutoProxyCreator, qui doit etre instanciee sous forme de Bean dans le conteneur 
leger : 

<bean class=" 

org.springf ramework. aop. framework. a utoproxy . Default Advisor AutoProxyCrea tor" /> 

Ce mode s'appuie sur les coupes gerees par Fensemble des advisors de l'application pour 
identifier les proxy a generer automatiquement. Dans notre exemple, les beans ayant une ou 
plusieurs methodes specifiees dans la coupe notifierPointcut sont automatiquement 
encapsules dans un proxy. 

Le second mode permet de specifier la liste des beans a encapsuler dans des proxy. Ce mode 
utilise la classe BeanNameAutoProxyCreator, qui doit etre instanciee sous forme de Bean dans le 
conteneur leger : 

<bean class=" org.springf ramework. aop. f ramework. autoproxy. BeanNameAutoProxyCreator "> 
<property name="beanNames" val ue="userManager"/> 
<property name=" intercept or Names "> 
<list> 

<val ue>notifierAdvisor</val ue> 
</list> 
</property> 
</bean> 
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Ce tisseur prend en parametre la liste des beans a tisser sous forme de tableau de chaines de 
caracteres via la propriete beanNames (l'utilisation du symbole * est autorisee) et la liste des 
advisors a y appliquer par le biais de la propriete interceptorNames. 

La propriete interceptorNames accepte aussi les greffons, mais cela implique que toutes les 
methodes de la cible sont interceptees, puisque la coupe n'est plus presente pour indiquer 
quelles sont les methodes a intercepter : 

<bean class=" org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator "> 
<property name="beanNames" val ue="userManager"/> 
<property name="i interceptor Names "> 
<1 1 st> 

<val ue>notifyAdvi ce </val ue> 

</list> 
</property> 
</bean> 

Les proxy specifiques 

De par leur mode de fonctionnement, les proxy specifiques sont plus etroitement controlables. 
lis permettent notamment de definir s'il faut creer un proxy par rapport a Finterface du Bean 
ou par rapport a sa classe, ainsi que le mode d'instanciation de Faspect (singleton ou par 
instance de Bean). 

Les proxy specifiques sont definis sous forme de beans avec la classe ProxyFactoryBean, qui, 
comme son nom Findique, est une fabrique de proxy. Ce sont ces beans qu'il faut utiliser en 
lieu et place des beans qu'ils encapsulent. Nous perdons ainsi la transparence des proxy auto- 
matiques du point de vue de la configuration. 

Si nous reprenons notre exemple introductif, la premiere etape consiste a renommer le Bean 
userManager en userManagerTarget (convention de nommage pour designer les beans devant 
etre tisses specifiquement). Ensuite, nous definissons un nouveau Bean userManager de la 
classe ProxyFactoryBean : 



<bean id="userManager" 



cl ass=" 


org. springf ramework. aop. framework. ProxyFactoryBean "> 


<property name="target" ref=" 


userManagerTarget 


" /> 





<property name=" interceptor Names "> 
<list> 

<val ue>notif ierAdvi sor</val ue> 
</list> 
</property> 
</bean> 

La propriete target specifie le Bean devant etre encapsule dans le proxy (ici, 
userManagerTarget). La propriete interceptorNames specifie la liste des advisors oudes greffons a 
tisser. 
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ProxyFactoryBean propose trois proprietes optionnelles : 

• proxy Interfaces : tableau de chaines de caracteres speciflant la liste des interfaces du Bean 
a tisser. Lorsque cette propriete n'est pas specifiee, la detection s'effectue automati- 
quement. 

• singleton : booleen speciflant le mode d'instanciation de l'aspect. S'il vaut false, l'aspect 
est instancie pour chaque instance du Bean tisse. Par defaut, cette propriete vaut true. 

• proxyTargetCl ass : booleen speciflant si le proxy doit etre genere sur la classe au lieu des 
interfaces qu'elle implemente. Par defaut, cette propriete vaut false. 



Modifications de cibles 

Comme indique a la section precedente consacree au tissage, un proxy encapsule un Bean afin 
d'intercepter les appels a ses methodes. Spring AOP propose un niveau d'indirection supple- 
mentaire grace a la notion de source de cible, modelisee par l'interface TargetSource du 
package org.springf ramework.aop. 

Cette notion est proche de celle de fabrique de Bean specifique. L'idee est que l'entite de reso- 
lution de la cible fournit au proxy la reference au Bean. Elle est done en mesure de controler 
cette derniere. Cette capacite permet de remplacer des beans a chaud ou de gerer des pools 
d' instances de beans. 

La fabrique ProxyFactoryBean utilise une implementation par defaut, qui renvoie la reference 
du Bean specifiee par sa propriete target. II est possible d'utiliser une des deux implementa- 
tions que nous allons voir grace a sa propriete targetSource. L'utilisation des sources de 
cibles est compatible avec le tissage d' aspect au sein de la fabrique. 

Remplacement a chaud des cibles 

Le remplacement a chaud des cibles permet de changer d' instance pour un Bean pendant 
l'execution de l'application. Ce remplacement a chaud est assure par la classe 
HotSwappabl eTarget Source du package org. spri ngf ramework.aop. target. 

Imaginons qu'un Bean TuduConnecti on dans Tudu Lists puisse etre change pendant l'execution de 
l'application. Un autre Bean, TuduConnecti onUser, aurait besoin d'une TuduConnecti on pour 
fonctionner. Ces classes sont Actives, elles n'ont pas d'utilite immediate dans Tudu Lists, si ce 
n'est illustrer notre propos. 

Voici la definition de l'interface TuduConnecti on : 
package tudu. aspects .target source; 

public interface TuduConnection { 
public String getNameO; 

} 

Voici une implementation tres simple de TuduConnecti on : 
package tudu. aspects. notify. impl ; 
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import tudu. aspects . targetsource.TuduConnecti on ; 
public class TuduConnectionlmpl implements TuduConnection { 
private String name; 

public TuduConnectionlmpl (String name) { 
this. name = name; 

} 

public String getNameO { 
return name; 

} 

} 

Enfin, void la classe TuduConnectionUser, qui utilise une TuduConnection : 
package tudu. aspects . targetsource; 

public class TuduConnectionUser { 

private TuduConnection tuduConnection; 

public TuduConnection getTuduConnection( ) { 
return tuduConnection; 

} 

public void setTuduConnection(TuduConnection tuduConnection) { 
this. tuduConnection = tuduConnection; 

} 

} 

Le fichier de configuration suivant permet d'initialiser le TuduConnectionUser avec une 
TuduConnection s'appelant original Bean : 

<bean id-"tuduConnectionTarget" 
class-" tudu. a spects.targetsource.impl .TuduConnectionlmpl "> 
<constructor-arg value="originalBean" /> 
</bean><^Q 

<bean id="tuduConnectionUser" 
class="tudu.aspects.targetsource.TuduConnectionUser"> 
<property name="tuduConnection" ref="tuduConnecti on" /> 
</bean><-0 

<bean id-"swapper" 
cl ass-" org. springf ramework. aop. target .Hot Swappabl eTarget Source "> 
Constructor- a rg ref="tuduConnectionTarget"/> 
</bean><— Q 



<bean id="tuduConnection" 
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class="org.springf ramework. aop. framework. Proxy Factory Bean" > 
<property name="targetSource" ref="swapper"/> 
</bean><-0 

La TuduConnection originale est creee avec le suffixe target, car elle va faire l'objet d'une 
decoration par un proxy (Q). L'utilisateur de la TuduConnecti onUser est ensuite cree et se voit 
injecte la TuduConnection {Q). II faut ensuite injecter la TuduConnection dans la 
HotSwappabl eTargetSource (Qi), qui va permettre d'effectuer le remplacement a chaud. Enfin, 
une ProxyFactoryBean, dans laquelle il faut injecter la HotSwappabl eTargetSource, va exposer 
la TuduConnection dans le contexte {Qi). 

Le remplacement a chaud se fait en recuperant le Bean swapper et en passant un nouveau Bean 
a sa methode swap. Toutes les references vers Fancien Bean sont alors mises a jour, et cela de 
maniere threadsafe. Voici un test unitaire illustrant le principe du remplacement a chaud (pour 
plus d'informations sur les tests unitaires, consulter le chapitre 6) : 

TuduConnecti onUser tuduConnectionUser = 
(TuduConnectionLlser) appContext .getBean( 
"tuduConnectionUser" 

); 

Assert. assert Equal s( 
"originalBean" , 

tuduConnectionUser. getTuduConnection( ) .getName( ) 
>;<-© 

HotSwappabl eTargetSource swappabl eTargetSource = (HotSwappabl eTargetSource) 
appContext. get Bean ( 
"swapper" 

); 

TuduConnection newTuduConnection = new TuduConnectionlmpl ( 
"newTuduConnection"<— Q 

); 

swappabl eTargetSource. swap(newTuduConnection) ;<— © 

Assert. assert Equal s( 
"newTuduConnection" , 

tuduConnectionUser. getTuduConnection( ) .getName( ) 

); 

Le test unitaire verifie en premier lieu que le TuduConnectionUser utilise bien la 
TuduConnection telle qu'elle a ete definie dans le contexte Spring {Q). Une nouvelle 
TuduConnection est ensuite creee avec un nouveau nom {Q). Cette nouvelle TuduConnection 
est passee a la methode swap de la HotSwappabl eTargetSource, qui effectue le remplacement a 
chaud et le propage a toutes les references vers l'ancienne TuduConnection {Q). Le test 
unitaire verifie enfin que le TuduConnectionUser utilise bien la nouvelle TuduConnection {Q). 
Le remplacement s'est done fait de facon transparente pour tous les beans utilisant la 
TuduConnection. 
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Pooling des cibles 

Spring AOP permet de creer un pool d' instances d'un Bean, similaire a celui propose par les 
serveurs d' applications avec les EJB Session sans etat. Pour cela, comme pour le remplace- 
ment a chaud des cibles, il faut utiliser une implementation specifique de TargetSource, ici 
CommonsPoolTargetSource, fondee sur la bibliotheque Commons Pool de la communaute 
Apache Jakarta. 

Le pooling de cibles s'avere utile pour les objets partages et non threadsafe. Le pooling de 
Spring permet de rendre l'appel d'une methode sur la cible threadsafe, car la cible sera recu- 
peree du pool et ne sera pas utilisee par un autre thread tant que la methode n'aura pas 
retourne son resultat. Si un autre thread a besoin de la cible, une instance du pool est utilisee. 
Linteret d' utiliser cette fonctionnalite avec Spring est que le pooling est transparent pour les 
beans utilisant la cible. 

Si nous reprenons les classes presentees a la section consacree au remplacement a chaud, il est 
possible d'effectuer du pooling sur la TuduConnection. II est important de noter que le Bean 
doit maintenant etre un prototype : 

<bean id-"tuduConnectionTarget" 

cl ass="tudu. aspects. notify .targetsource.impl .TuduConnectionlmpl " 

scope=" prototype "> 

<constructor-arg val ue="pool abl eBean" /> 
</bean> 

<bean id="pool" 

cl ass-" org. springframework.aop. target .Commons Pool TargetSource "> 
<property name="targetBeanName" val ue="tuduConnectionTarget" /> 
<property name="maxSize" value="10" /> 
</bean> 

<bean id="tuduConnection" 
cl a ss=" org. springf ramework. aop. framework. Proxy Factory Bean "> 
<property name-"targetSource" ref="pool" /> 
</bean> 

Dans cet exemple, nous creons un pool d'instances du Bean tuduConnection ayant au maximum 
dix instances disponibles. 



Preconisations 

Le fait que Spring propose differents moyens d'effectuer de la POA est assez deroutant, puis- 
que Ton ne sait quelle solution retenir. Nous avons choisi de presenter Spring AOP classique, 
afin que les personnes utilisant ce systeme retrouvent leurs mai - ques et puissent faire une tran- 
sition plus aisee vers le support AspectJ de Spring. Nous preconisons d' utiliser le support 
AspectJ de Spring pour tout nouveau projet, car il se revele plus souple, plus puissant et plus 
precis que Spring AOP classique. II faut ensuite determiner quelle approche utiliser : annotations 
ou configuration XML. 
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Les annotations presentent l'avantage d'eviter un fichier de configuration supplementaire. Des 
aspects annotes peuvent aussi directement etre reutilises avec une solution 100 % AspectJ, 
sans Spring. En revanche, les annotations fixent assez fortement les aspects a F application, 
enlevant ainsi de la reutilisabilite d'une application a Fautre. De plus, les annotations necessitent 
une machine virtuelle Java 1 .5 ou plus. 

La configuration XML permet que les greffons completement POJO (si Ton ne fait pas 
d' introspection avec un JoinPoint) soient utilisables sur une machine virtuelle 1.4 (avec 
Spring 2.5). De plus, elle permet de centraliser facilement toute la configuration de la POA, 
dans un seul fichier. La POA d'une application peut ainsi etre desactivee en supprimant le 
chargement du fichier conceme. 

L'un des inconvenients de la configuration XML est qu'elle oblige de maintenir un fichier 
supplementaire. Son autre inconvenient est d'empecher la reutilisation directe des greffons 
dans un environnement 100 % AspectJ. 



Conclusion 

Nous avons vu comment utiliser Spring AOP et son support d' AspectJ pour faire de la POA. 
Nous avons implemente a cet effet la notification evoquee au chapitre precedent, afin de 
demontrer concretement la puissance de ce paradigme. 

Grace a la richesse de Spring AOP, le developpeur dispose d'une large palette d'outils pour 
definir les aspects qui lui sont necessaires. Cependant, Spring AOP n'offre pas toute la 
richesse fonctionnelle des outils de POA specialises. II ne peut, par exemple, intercepter que 
les executions de methodes des beans geres par le conteneur leger. 

La couverture fonctionnelle de ce framework reste cependant suffisante pour couvrir la 
plupart des besoins. La gestion des transactions, que nous traitons en detail au chapitre 11, 
repose d'ailleurs sur Spring AOP, preuve concrete que ce framework est en mesure de supporter 
des aspects complexes. 
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Les tests sont une des activites fondamentales du developpement logiciel. Ce chapitre montre 
comment tester une application reposant sur Spring. Les types de tests abordes sont les tests 
unitaires et les tests d' integration. 

Par tests unitaires, nous entendons les tests portant sur un composant unique isole du reste de 
l'application et de ses composants techniques (serveur d' applications, base de donnees, etc.). 
Par tests d' integration, nous entendons les tests portant sur un ou plusieurs composants, avec 
les dependances associees. II existe bien entendu d'autres types de tests, comme les tests de 
performance ou les tests fonctionnels, mais Spring ne propose pas d'outil specifique dans ces 
domaines. 

Nous nous arreterons de maniere synthetique sur deux outils permettant de realiser des tests 
unitaires, le framework JUnit et EasyMock, ce dernier permettant de realiser des simulacres 
d'objets, ou mock objects. Ces deux outils nous fourniront Foccasion de detailler les concepts 
fondamentaux des tests unitaires. Nous verrons que Futilisation de ces outils est toute natu- 
relle pour les applications utilisant Spring, puisque le code de ces dernieres ne comporte pas 
de dependance a l'egard de ce framework du fait de l'inversion de controle. Spring propose 
d'ailleurs ses propres simulacres pour emuler une partie de FAPI Java EE. 

Pour les tests d' integration, nous nous interesserons aux extensions de JUnit fournies par 
Spring et par le framework DbUnit, specialise dans les tests de composants de persistance des 
donnees. La encore, les tests s'averent aises a implemented ces extensions prenant en charge 
les problematiques techniques les plus courantes. 
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Pourquoi ecrire des tests ? 

L'ecriture de tests peut paraitre paradoxale au premier abord : ecrire un programme pour en 
tester un autre. De plus, l'ecriture de test peut paraitre consommatrice de temps, puisqu'elle 
correspond a l'ecriture de code supplementaire. Cependant, les tests presentent un ensemble 
d'avantages qui les rendent indispensables a tout developpement informatique se voulant 
robuste et evolutif. 

Les tests permettent de guider la conception. En effet, un code difficilement testable est en 
general un code mal concu. Le rendre facilement testable, unitairement ou via un test d' inte- 
gration, est sans conteste une avancee vers un code mieux concu. 

Les tests ecrits sous forme de programme resistent a l'epreuve du temps, contrairement aux 
tests manuels. C'est pour cette raison que les tests font completement partie d'un projet et 
doivent etre sauvegardes sur un depot de sources, tout comme le code de 1' application. 

Les tests sont enfin un element essentiel dans la vie d'une application car ils lui permettront 
d'evoluer et de s'adapter aux nouveaux besoins. II est rare qu'une application ne doive pas 
etre modifiee au cours de sa vie afin de repondre a de nouveaux besoins. Sans tests unitaires, 
les modifications necessaries se feront generalement dans la crainte de regressions (« casser » 
des fonctionnalites existantes en en rajoutant d'autres). Cette crainte ne facilite pas un raison- 
nement global, qui privilegierait des modifications de conception plutot que des modifications 
se rapprochant du « bricolage ». Avec des tests unitaires offrant une bonne couverture, les 
modifications se font plus sereinement. Des modifications plus profondes sont favorisees par 
les tests unitaires qui permettent de mettre en evidence les regressions. Avec une telle appro- 
che, la qualite de l'application et son adaptability ne se degradent pas avec le temps mais 
s'ameliorent. 

Les tests ne sont pas la panacee ; ils ne permettront pas systematiquement a une application 
d'etre sans faille, car ils doivent etre ecrits avec soin. Ils constituent cependant un engrenage 
essentiel dans la mecanique globale de tout developpement informatique. 



Les tests unitaires avec JUnit 

JUnit est un framework Java Open Source cree par Erich Gamma et Kent Beck. II fournit un 
ensemble de fonctionnalites permettant de tester unitairement les composants d'un logiciel 
ecrit en Java. D'autres frameworks suivant la meme philosophie sont disponibles pour 
d'autres langages ou pour des technologies specifiques, comme HTTP. Ils constituent la 
famille des frameworks xUnit. 

Initialement concu pour realiser des tests unitaires, JUnit peut aussi etre utilise pour realiser 
des tests d'integration, comme nous le verrons plus loin dans ce chapitre. 

Dans les sections suivantes, nous indiquons comment manipuler les differents elements four- 
nis par JUnit afin de creer des tests pour le module « core » de Tudu Lists. Dans cette applica- 
tion, F ensemble des cas de tests est regroupe dans le repertoire src/test/java. Les differents 
tests sont organises selon les classes qu'ils ciblent. Ainsi, ils reproduisent la structure de 
packages de Tudu Lists. 
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La version de JUnit etudiee ici est la 4.5. Elle privilegie Futilisation d'annotations pour definir 
les tests plutot que 1' heritage d'une classe de test (et des conventions de nommage), comme sa 
version 3.8, encore certainement la plus utilisee. Cette approche par annotations favorise le 
modele POJO puisque le framework est relativement peu intrusif (pas de necessite d' heri- 
tage). Elle est aussi plus souple et s'avere tres bien supportee par Spring. C'est pour cet 
ensemble de raisons que nous avons prefere l'etude de cette nouvelle version. 



Les cas de test 

Les cas de test sont une des notions de base de JUnit. II s'agit de regrouper dans une entite 
unique, en F occurrence une classe Java annotee, un ensemble de tests portant sur une classe 
de F application. 

Chaque test est materialise sous la forme d'une methode sans parametre, sans valeur de retour 
et portant Fannotation org. junit. Test. Le nom de la classe regroupant les tests d'une classe 
est conventionnellement celui de la classe testee suffixee par Test (par exemple, 
TodosManagerlmplTest). 

Squelette d'un cas de test 

Pour introduire la notion de cas de test, nous allons utiliser la classe Todo definie dans le 
package tudu. domain. model. Cette classe definit deux methodes, compareTo (methode de 
l'interface java.lang. Comparable) et equals (heritee de java.lang. Object). 

Pour tester ces deux methodes, nous allons creer plusieurs instances de la classe Todo et effec- 
tuer des comparaisons ainsi que des tests d'egalite. Nous definissons pour cela une classe 
TodoTest ayant deux methodes, compareTo et equals : 

package tudu. domain. model ; 

import org. junit. Test; 

public class TodoTest { 

(...) 

©Test 
publ i c 
(.. 

} 

©Test 

publ i c void equal s( ) { 
(...) 

} 

} 



void compareToO { 
.) 
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Notons que la classe de test ne depend d'aucune classe par un heritage ou d'une interface par 
une implementation. De plus, les methodes de tests portent directement le nom des methodes 
testees. 

La notion de fixture 

Dans JUnit, la notion de fixture, ou contexte, correspond a un ensemble d'objets utilises par 
les tests d'un cas. Typiquement, un cas est centre sur une classe precise du logiciel. II est done 
possible de definir un attribut ayant ce type et de l'utiliser dans tous les tests du cas. II devient 
alors une partie du contexte. Le contexte n'est pas partage par les tests, chacun d'eux posse- 
dant le sien, arm de leur permettre de s'executer independamment les uns des autres. II est 
important de noter qu'avec JUnit, le contexte est initialise pour chacune des methodes d'une 
classe de test. 

Avec JUnit, il est possible de mettre en place le contexte de plusieurs manieres. La maniere la 
plus simple consiste a annoter des methodes avec l'annotation org. j unit. Before. Ces metho- 
des doivent avoir une signature de type public voi d. Si F initialisation du contexte alloue des 
ressources specifiques, il est necessaire de liberer ses ressources. Cela se fait en annotant des 
methodes avec l'annotation org. junit. After. Les methodes annotees pour la destruction du 
contexte ont les memes contraintes que son initialisation. II est done frequent que toute 
methode d'initialisation ait son pendant pour la destruction du contexte. 

Dans JUnit 3, le cycle de vie du contexte etait gere par la surcharge de deux methodes : setup 
et tearDown. II est done frequent d'adopter cette nomenclature avec l'approche annotations. 

La gestion du contexte peut done se definir de la maniere suivante : 
public class TodoTest { 

©Before 

publ i c void setUp( ) { 

// Creation du contexte 

} 

©After 

public void tearDownO { 

// Destruction du contexte 

} 

(...) 

} 

Pour les tests de la classe Todo, nous pouvons creer un ensemble d'attributs de type Todo qui 
nous serviront de jeu d'essai pour nos methodes de test : 

public class TodoTest { 

private Todo todol; 
private Todo todo2; 
private Todo todo3; 
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©Before 

publ i c void setUp( ) { 

todol = new Todo( ) ; 

todol.setTodoIdCOl" ); 

todol . setCompl eted(f al se) ; 

todol . set Descripti on ( "Description" ) ; 

todol. setPriority(O) ; 

todo2 = new Todo( ) ; 

todo2.setTodoId("02"); 

todo2.setCompleted(true) ; 

todo2. set Descripti on ("Descripti on") ; 

todo2.setPriority(0) ; 

todo3 = new Todo( ) ; 

todo3.setTodoId("01"); 

todo3. setCompl eted(f al se) ; 

todo3 . set Descripti on ( "Description" ) ; 

todo3.setPriority(0) ; 

} 

(...) 

} 

Les assertions et I'echec 

Dans JUnit, les assertions sont des methodes permettant de comparer une valeur obtenue lors 
du test avec une valeur attendue. Si la comparaison est satisfaisante, le test peut se poursuivre. 
Dans le cas contraire, il echoue, et un message d'erreur s'affiche dans l'outil permettant 
d'executer les tests unitaires. 

Les assertions peuvent etre effectuees avec des appels a des methodes statiques de la classe 
org. junit. Assert. Leur nom est prefixe par assert. 

Pour les booleens, les assertions suivantes sont disponibles : 

assertFalse (boolean obtenu); 
assertTrue (boolean obtenu); 

Elles testent le booleen obtenu sur les deux valeurs litterales possibles, faux ou vrai. 
Pour les objets, les assertions suivantes sont disponibles, quel que soit leur type : 

assertEquals (Object attendu, Object obtenu); 
assertSame (Object attendu, Object obtenu); 
assertNotSame (Object attendu, Object obtenu); 
assertNull (Object obtenu); 
assertNotNul 1 (Object obtenu); 

assertEquals teste l'egalite de deux objets tandis qu'assertSame teste que attendu et obtenu 
font reference a un seul et meme objet. Par exemple, deux objets de type java.util .Date 
peuvent etre egaux, c'est-a-dire contenir la meme date, sans etre pour autant un seul et meme 
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objet. assertNotSame verifie que deux objets sont differents. Les deux dernieres assertions 
testent si F objet obtenu est nul ou non. 

Pour les differents types primitifs (long, double, etc.), une methode assertEquals est definie, 
permettant de tester Fegalite entre une valeur attendue et une valeur obtenue. Dans le cas des 
types primitifs correspondant a des nombres reels (doubl e), un parametre supplemental, le delta, 
est necessaire, car les comparaisons ne peuvent etre tout a fait exactes du fait des arrondis. 

II existe une variante pour chaque assertion prenant une chaine de caracteres en premier para- 
metre (devant les autres). Cette chaine de caracteres contient le message a afficher si le test 
echoue au moment de son execution. Si Fechec d'une assertion n'est pas evident, il est en 
effet important de preciser la raison de Fechec avec un message. 

Les assertions ne permettent pas de capter tous les cas d'echec d'un test. Pour ces cas de 
figure, JUnit fournit la methode f ai 1 sous deux variantes : une sans parametre et une avec un 
parametre, permettant de dormer le message d'erreur a afficher sous forme de chaine de carac- 
teres. Lappel a cette methode entraine F arret immediat du test en cours et Faffiche en erreur 
dans Foutil d'execution des tests unitaires. 

Les tests unitaires n'heritant d'aucune classe, ils doivent appeler les methodes d'assertions 
directement, par exemple : 

Assert .a ssertTrue(someBool eanVal ue) ; 

Cette syntaxe peut etre simplified via un import statique : 

import static org. junit. Assert.*; 

(...) 

// dans une methode de test : 
assertTrue(someBool eanVal ue) ; 

Si nous reprenons notre exemple TodoTest, il se presente desormais de la maniere suivante : 

public class TodoTest { 

(...) 

©Test 

public void compareToO { 

// Verifie la consistance avec la methode equals 
// Cf . JavaDoc de 1 'API J2SE 
assertTrue(todol .compareTo(todo3)=-0) ; 

// Verifie le respect de la spec de Comparable pour null 
// Cf . JavaDoc de 1 'API J2SE 
try { 

todol . compareTo(nul 1 ) ; 
failO; 

} 

catch(Nul 1 PointerException e){ 
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// OK 

} 

// todol n'est pas ferme done < a todo2 
assertTrue(todol .compareTo(todo2)<0) ; 

// Verifie que 1 'inverse est vrai aussi 
assertTrue(todo2.compareTo(todol)>0) ; 

} 

©Test 

publ i c void equal s( ) { 

assert Equal s( todol ,todo3) ; 
assertFal se (todol .equal s(todo2) ) ; 

} 

} 

Execution des tests 

Une fois les cas de test et les suites de tests definis, il est necessaire de les executer pour verifier 
le logiciel. 

Le lanceur standard de JUnit 

JUnit introduit la notion de lanceur pour executer les tests et propose un lanceur par defaut. 
II est textuel et utilise en fait une classe ecrite pour JUnit 3, le motif de conception adaptateur 
etant utilise pour que des tests JUnit 4 puissent etre lances. 

Pour utiliser ce lanceur en mode texte dans un cas de test (ici la classe TodoTest), il suffit d'y 
ajouter une methode main de la maniere suivante : 

public static void main(String[] args) { 
junit.textui .TestRunner . run( 

new JUni t4TestAdapter( TodoTest .cl ass) 

); 

} 

La classe junit.textui .TestRunner est appelee en lui passant en parametre la classe du cas de 
test (et non une instance) a executer, via un adaptateur pour JUnit 4. Cette methode mai n peut 
etre ecrite soit directement dans la classe du cas de test, comme dans cet exemple, soit dans 
une classe specifique. 

Si nous executons TodoTest, nous obtenons le resultat suivant dans la console Java : 



Time: 0,047 
OK (2 tests) 



Ce resultat indique de maniere laconique que les deux tests definis dans TodoTest se sont bien 
executes. 
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Le lanceur integre a JUnit a le merite d'exister, mais il sert principalement a illustrer Futilisation 
du framework et on lui prefere generalement d'autres lanceurs, selon les besoins. 

Le lanceur JUnit integre a Eclipse 

Eclipse propose son propre lanceur JUnit, parfaitement integre a Fenvironnement de develop- 
pement. 

Pour l'utiliser, il n'est pas necessaire de creer une methode mai n specifique dans les cas de test, 
a la difference des lanceurs standards. II suffit de selectionner l'explorateur de package et le 
fichier du cas de test par clic droit et de choisir Run dans le menu contextuel. Parmi les choix 
proposes par ce dernier, il suffit de selectionner JUnit Test. 

Une vue JUnit s'ouvre alors pour nous permettre de consulter le resultat de Fexecution des 
tests. Si tel n'est pas le cas, nous pouvons l'ouvrir en choisissant Window puis Show view et 
Other. Une liste hierarchisee s'affiche, dans laquelle il suffit de selectionner JUnit dans le 
dossier Java et de cliquer sur le bouton OK ( voir figure 6-1 ). 



Figure 6-1 
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a Eclipse 
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L'interet de ce lanceur reside dans sa gestion des echecs apres Fexecution des tests. 

Si nous modifions TodoTest de maniere que deux tests echouent (il suffit pour cela de mettre 
une valeur attendue absurde, qui ne sera pas respectee par la classe testee), nous obtenons 
dans le lanceur le resultat illustre a la figure 6-2. 



Figure 6-2 

Gestion des echecs dans 
la vue JUnit d' Eclipse 
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Les echecs (failures) sont indiques par une croix bleue et les succes par une marque verte. En 
cliquant sur un test ay ant echoue, la trace d' execution est affichee dans la zone Failure Trace. 
En double-cliquant sur le test, son code source est immediatement affiche dans l'editeur de 
code d'Eclipse. 

A partir des resultats des tests, le developpeur peut naviguer directement dans son code et le 
corriger dans Eclipse, ce qui n'est pas possible avec les lanceurs standards de JUnit. 

Lanceurs integres a la construction d'un projet 

Les tests unitaires font completement partie du code source d'un projet ; il n'y a done aucune 
raison pour que leur execution ne fasse pas partie du processus de construction (« build ») 
d'un projet. 

Les principaux outils de construction en Java (Ant, Maven) disposent done de systemes 
d'execution des tests unitaires. La construction de Tudu Lists est faite avec Maven 2, outil qui 
integre le lancement des tests unitaires via le plugin Surefire. Maven 2 lance tous les tests se 
trouvant dans un repertoire donne (generalement sre/test/java). Le plugin Surefire est capable 
de lancer differents types de tests (JUnit 3 et 4, TestNG). Les resultats des tests sont stockes 
sous forme de fichiers (texte et XML), qui sont ensuite transformes pour generer des rapports 
plus lisibles, au format HTML. 

La figure 6-3 illustre des rapports de tests unitaires pour la partie core de Tudu Lists. 
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Rapports de tests unitaires avec Maven 2 
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Quel que soit le systeme utilise, il est essentiel d'incorporer le lancement des tests unitaires au 
processus de construction et d' avoir un moyen de communiquer les resultats, arm d' avoir une 
idee precise de la sante du projet. 

En resume 

Lecriture de tests avec JUnit n'est pas intrinsequement compliquee. Cependant, il faut 
garder a l'esprit que cette simplicite d'utilisation depend fortement de la facon dont l'appli- 
cation est concue. La mise en ceuvre de tests unitaires dans une application mal concue et 
qui, par exemple, ne montre aucune structuration peut s'averer tres difficile, voire parfaite- 
ment impossible. 

L' utilisation de JUnit est rendue efficace grace aux principes architecturaux que doivent appliquer 
les applications Spring, a savoir l'inversion de controle apportee par le conteneur leger et la 
separation claire des couches de 1' application. Grace a ces principes, les composants se 
revelent plus simples a tester, car ils se concentrent dans la mesure du possible sur une seule 
preoccupation. 

En complement de JUnit, il est necessaire d'utiliser des simulacres d'objets afin d'isoler des 
contingences exterieures le composant a tester unitairement. C'est ce que nous allons voir a la 
section suivante. 

Les simulacres d'objets 

Le framework JUnit constitue un socle pour realiser des tests, mais il n'offre aucune fonction- 
nalite specifique pour tester les relations entre les differents objets manipules lors d'un test. 
II est de ce fait difficile d'isoler les dysfonctionnements de l'objet teste de ceux qu'il mani- 
pule, ce qui n'est pas souhaitable lorsque nous realisons des tests unitaires. Lidee est en effet 
de tester seulement une classe et de ne pas dependre des classes qu'elles utilisent. 

Afin de combler ce vide, il est possible d'utiliser des simulacres d'objets (mock objects). 
Comme leur nom l'indique, ces simulacres simulent le comportement d'objets reels. II leur 
suffit pour cela d'heriter de la classe ou de l'interface de l'objet reel et de surcharger chaque 
methode publique utile au test. Le comportement de ces methodes est ainsi redefini selon un 
scenario concu specifiquement pour le test unitaire et done parfaitement maitrise. 

Par exemple, si nous testons un objet faisant appel a un DAO, nous pouvons remplacer ce 
dernier par un simulacre. Ce simulacre ne se connectera pas a la base de donnees, mais 
adoptera un comportement qui lui aura ete dicte. Ce comportement consistera generate - 
ment a retourner certaines donnees en fonction de certains parametres. Nous isolons de la 
sorte l'objet teste des contingences specifiques au DAO (connexion a la base de donnees, 
etc.). 

Differences entre simulacres et bouchons 

Lidee d'utiliser des implementations de test en lieu et place de veritables implementations est 
une pratique assez commune. Cependant ces implementations de tests se presentent sous 
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differentes formes. De facon generate, les implementations destinees seulement aux tests sont 
appelees des « doublures » (en reference aux doublures dans les films d' action). II existe 
differents types de doublures, notamment les simulacres et les bouchons (respectivement 
mock et stubs). 

Les bouchons sont generalement de veritables implementations, dans le sens ou du code a ete 
ecrit pour les implemented Leur comportement est limite a ce qu'a prevu le developpeur pour 
le test. lis peuvent maintenir des informations sur les appels auxquels ils ont du repondre (par 
exemple, une variable permettant de dire qu'un e-mail a ete envoye). 

Les simulacres sont des objets preprogrammes avec un ensemble d'expectations qui consti- 
tuent une specification de la sequence d'appels qu'ils sont censes recevoir. II s'agit, par exem- 
ple, de dire que la methode getProperty doit etre appelee en tout deux fois, la premiere avec 
le parametre smtp . host et la seconde avec le parametre smtp . user. Le simulacre peut aussi etre 
programme pour renvoyer une certaine valeur pour chacun des appels. Les comportements 
des simulacres pouvant etre complexes, des implementations figees (bouchons) ne peuvent 
convenir, d'ou la necessite d'un outillage pour generer ces objets. 

Lecriture de bouchons est generalement specifique a un projet et necessite plus de bon sens 
que de technique. Notre etude se limitera done aux simulacres. 



Les simulacres d'objets avec EasyMock 

Plusieurs frameworks permettent de creer facilement des simulacres au lieu de les developper 
manuellement. Pour les besoins de Fouvrage, nous avons choisi EasyMock, qui est l'un des 
plus simples d'utilisation. 

EasyMock est capable de creer des simulacres a partir d'interfaces. Une extension permet 
d'en fournir a partir de classes, mais nous ne l'abordons pas ici, puisque, dans le cas d' appli- 
cations Spring, nous utilisons essentiellement des interfaces. 

Cette section n'introduit que les fonctionnalites principales d'EasyMock. Nous utilisons la 
version 2.4, qui fonctionne avec Java 5. Pour plus d'informations, voir le site Web dedie au 
framework, a l'adresse http://www.easymock.org. 

Les simulacres simples 

Les simulacres dits simples renvoient generalement des valeurs predefinies. Leur comportement 
se rapproche de celui des bouchons. Leur avantage reside dans leur caractere dynamique, car ils 
sont facilement modifiables. Ils ne necessitent pas non plus de creer de classe specifique. 

Supposons que nous desirions tester de facon unitaire la classe ConfigurationManagerlmpl en 
charge de la configuration des parametres de F application Tudu Lists. Cette classe possede 
une dependance vis-a-vis de Finterface PropertyDAO. Pour pouvoir Fisoler des contingences 
liees a F implementation fournie par Tudu Lists de cette interface, il est necessaire de creer un 
simulacre dont nous controlons tres exactement le comportement. 
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Avant de programmer notre simulacre, definissons rapidement son comportement au moyen 
de la methode getProperty, seule utile pour notre test : 

• Si le parametre de getProperty vaut key, renvoyer un objet Property dont l'attribut key vaut 
key et dont l'attribut val ue vaut val ue. 

• Dans tous les autres cas, renvoyer par defaut un objet Property dont les attributs key et val ue 
valent tous les deux def aul t. 

Maintenant que nous avons defini les comportements du simulacre, nous pouvons le definir au 
sein d'un cas de test : 

package tudu. service. impl ; 

import static org.easymock.EasyMock.*;<— © 

import org. junit. After; 
import org. junit. Before; 
import org. junit. Test; 

import tudu. domain .dao. PropertyDAO; 
import tudu. domain. model .Property; 

public class ConfigurationManagerlmpl ECTest { 

private PropertyDAO propertyDAO = null; 

private ConfigurationManagerlmpl configurationManager = null; 
©Before 

public void setUpO throws Exception { 

propertyDAO = createMock( PropertyDAO. cl ass) ;<— © 
configurationManager = new ConfigurationManagerlmpl () ; 
configurationManager. set Property DAO (property DAO) ;<— © 

} 

©Test 

public void getProperty( ) { 

Property property = new PropertyO; 
property . setKeyt "key" ) ; 
property . setVal ue( "val ue" ) ; 
expect (property DAO. get Property ( "key" ) ) 
.andStubReturn(property) ;<— © 



Property def aul tProperty = new PropertyO; 
def aul tProperty . set Key ( "default" ) ; 
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defaul t Property .setVal ue( "default" ) ; 
expect ( property DAO. get P rope rty( (String)anyObject( ) ) ) 
. andStubReturn ( defaul t Property ) ;<— © 

repl ay(propertyDAO) ;<— © 

Property test = configurationManager.getPropertyC'key") ; 
assert Equal s( "val ue" , test .getVal ue( ) ) ; 
test = configurationManager.getPropertyC'anything") ; 
assert Equal s( "defaul t" , test .getVal ue( ) ) ; 

verify(propertyDAO) ;<— © 

} 

} 

Pour simplifier Fecriture du code necessaire a la definition des simulacres, des imports stati- 
ques, nouveaute introduite avec Java 5, sont utilises (©). Les imports statiques permettent de 
ne plus avoir a specifier la classe (en Foccurrence la classe org.easymock. EasyMock) lors des 
appels a ses methodes statiques. 

Nous avons defini une methode de gestion de contexte en utilisant Fannotation org. j unit. Before. 
Par convention, nous avons appele cette methode setup. Elle cree le simulacre et l'injecte dans le 
manager. La creation du simulacre consiste a creer une instance d'objet implementant 1' interface 
PropertyDAO en utilisant la methode createMock (©). Cette methode prend en parametre Finterface 
que le simulacre doit implemented en Foccurrence PropertyDAO. 

Une fois le simulacre cree, nous Finjectons manuellement dans le manager, puisque nous 
sommes dans le cadre de tests unitaires, c'est-a-dire sans conteneur (©). 

Pour que le simulacre fonctionne, il est necessaire de specifier le comportement de chacune de 
ses methodes publiques utilisees dans le cadre du test. C'est ce que nous faisons au debut de 
la methode getProperty (©, ©) en utilisant la methode statique expect de la classe EasyMock. 

Au repere©, nous specifions le comportement de la methode getProperty de propertyDAO 
lorsque celle-ci a comme parametre key, c'est-a-dire la valeur que la methode doit renvoyer, 
en Foccurrence Fobjet property. Pour cela, nous passons en parametre a expect Fappel a 
getProperty proprement dit. Nous utilisons ensuite la methode andStubReturn de Fobjet 
renvoye par expect pour specifier la valeur de retour correspondant au parametre key. 

Au repere ©, nous specifions le comportement par defaut de getProperty, c'est-a-dire quel 
que soit son parametre. Pour indiquer que le parametre attendu peut etre n'importe lequel, 
nous utilisons la methode anyObject d'EasyMock. La valeur de retour est, la encore, specifiee 
avec la methode andStubReturn. 

Pour pouvoir executer le test unitaire proprement dit, il suffit d'appeler la methode repl ay en 
lui passant en parametre le simulacre (©). Nous indiquons ainsi a EasyMock que la phase 
d'enregistrement du comportement du simulacre est terminee et que le test commence. 
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Une fois le test termine, un appel a la methode veri f y (Q) permet de verifier que le simulacre 
a ete correctement utilise (c'est-a-dire que toutes les methodes ont bien ete appelees). 

Si nous executons notre test unitaire, nous constatons que tout se deroule sans accroc, comme 
Fillustre la figure 6-4. 



Figure 6-4 

Execution du cas de test 
avec bouchon 
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Notons que si une methode dont le comportement n'est pas defini est appelee, une erreur est 
generee. II est possible d'affecter un comportement par defaut a chaque methode en utilisant 
la methode createNiceMock au lieu de createMock. Son interet est toutefois limite, car ce 
comportement consiste a renvoyer 0, fal se ou nul 1 comme valeur de retour. 

Les simulacres avec contraintes 

Le framework EasyMock permet d'aller plus loin dans les tests d'une classe en specifiant la 
facon dont les methodes du simulacre doivent etre utilisees. 

Au-dela de la simple definition de methodes bouchons, il est possible de definir des contrain- 
tes sur la fa?on dont elles sont utilisees, a savoir le nombre de fois ou elles sont appelees et 
Fordre dans lequel elles le sont. 

Definition du nombre d'appels 

EasyMock permet de specifier pour chaque methode bouchon des attentes en termes de 
nombre d'appels. La maniere la plus simple de definir cette contrainte consiste a ne pas definir 
de valeur par defaut, autrement dit a supprimer le code au niveau du repere © et a remplacer 
la methode andStubReturn par la methode andReturn. 

EasyMock s' attend alors a ce qu'une methode soit appelee une seule fois pour une combinai- 
son de parametres donnee. Si, dans l'exemple precedent, apres ces modifications, nous appe- 
lons la methode getProperty avec le parametre key deux fois dans notre test, une erreur 
d'execution est generee, comme Fillustre la figure 6-5. 
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Figure 6-5 

Appel inattendu a la 
methode getProperty 



= Failure Trace 

j ava . I a n g . A ssertionError 
Unexpected method call getProperty("key"): 

getProperty("key"): expected: 1, actual: 1 (+1) 
at org.easymock.internal.MocklnvocationHandler.invoki 
at org.easymock.internal.ObjectMethodsFilter.invoke(0 
at $Proxy5.getProperty(Unknown Source) 
at tudu. service. impl.ConfigurationManagerlmpl.getProf 
at tudu. service. impl.ConfigurationManagerlmplTest.get 



L'erreur affichee indique que l'appel a la methode getProperty est inattendu (unexpected). Le 
nombre d' appel de ce type attendu (expected) et effectif (actual) est precise. En F occurrence, 
le nombre attendu d'appel est 1, et le nombre effectif 2(1 + 1). 

De meme, si la methode getProperty n'est pas appelee avec le parametre key, une erreur est 
generee puisque EasyMock s'attend a ce qu'elle soit appelee une fois de cette maniere. 

Pour definir le nombre de fois ou une methode doit etre appelee, nous disposons des quatre 
methodes suivantes, a utiliser sur le resultat produit par andReturn : 

• times (int nbre) : specifie un nombre d'appels exact. 

• times (int min.int max) : specifie un nombre d'appels borne. 

• atLeastOnce : specifie que la methode doit etre appelee au moins une fois. 

• anyTimes : le nombre d'appels est quelconque (y compris 0). 
Le code ci-dessous specifie un nombre d'appels egal a 2 : 

expect ( property DAO. get P rope rty( "key") ) 
.and Ret urn (property) .times(2) ; 

Si nous executons notre test appelant deux fois getPropertyC'key") avec ce nouveau simulacre, 
nous n'obtenons plus d' erreur. 

Definition de I'ordre d'appel des methodes 

L'ordre d'appel des methodes peut etre important pour tester la facon dont un objet manipule 
les autres. Avec EasyMock, nous pouvons definir l'ordre dans lequel les methodes d'un simu- 
lacre doivent etre appelees. 

Pour tenir compte de l'ordre, il suffit de remplacer la methode createMock du controleur par 
createStrictMock. L'ordre d'appel des methodes est alors defini par la sequence de leur appel 
pour la definition du simulacre. 

Pour tester l'effet de cette modification, modifions le code de notre test. Juste apres le 
repere 0. definissons le comportement de getProperty avec le parametre another : 

anot her Property . set Key ( "another" ) ; 
anot her Property . setVal ue( "something" ) ; 
expect(propertyDAO.getProperty( "another" ) ) 
.andReturn(anotherProperty) ; 
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Introduisons ensuite le test suivant juste apres le premier test de la methode getProperty : 

test = configurationManager.getPropertyC'another") ; 
assert Equal s( "something" , test.getVal ue( ) ) ; 

Si nous effectuons cette modification sur le code precedent sans autre modification, nous obte- 
nons le resultat illustre a la figure 6-6. 



L'erreur indique que la valeur de retour attendue etait celle du comportement par defaut, puis- 
que le comportement avec le parametre another a ete defini apres le comportement avec le 
parametre key, qui n'a pas encore ete appele. 

Les simulacres d'objets de Spring 

Spring n'etant pas un framework dedie aux tests unitaires, il ne fournit pas de services similai- 
res a ceux d'EasyMock. Cependant, afin de faciliter l'ecriture de tests unitaires, Spring fournit 
un ensemble de simulacres prets a Femploi. Ces simulacres simulent des composants standards 
de 1' API Java EE souvent utilises dans les applications. 

L' ensemble de ces simulacres est defini dans des sous-packages de org. spring- 
framework. mock. 

Les simulacres Web 

Dans le package org. springframework. mock. web, sont definis les simulacres necessaires pour 
tester des composants Web. Nous y trouvons des simulacres pour les principales interfaces de 
FAPI servlet, notamment les suivants : 

• HttpServl etRequest 

• HttpServl etResponse 

• HttpSession 

Dans Tudu Lists, nous disposons d'une servlet pour effectuer la sauvegarde du contenu d'une liste 
de todos. Le code suivant, extrait de la classe BackupServletTest du package tudu. web. servlet, 
montre comment les simulacres Web MockHttpServl etRequest, MockHttpServl etResponse et 
MockHttpSessi on sont utilises pour tester cette servlet dans un cas de test JUnit classique : 




Figure 6-6 

Resultat du non-respect 
de I'ordre d'appel 




org.junit.ComparisonFailure: expected:<[something]> but was:<[default]> 
= at tudu.service.impl.ConfigurationManagerImplTest.getProperty(Configurati( 



©Test 



public void doGetO throws Exception { 
Document doc = new DocumentO; 

Element todoLi stEl ement = new El ement( "todol i st" ) ; 
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todoLi stEl ement .addContent( 

new El ement( "titl e" ). addContent( "Backup List")); 
doc. addContent(todol_i stEl ement) ; 

MockHttpServl etRequest request = new MockHttpServl etRequest( ) ; 
MockHttpSessi on session = new MockHttpSession( ) ; 
session. setAttri bute( "todoLi stDocument" , doc) ; 
request. setSess ion (session) ; 

MockHttpServl etResponse response = 
new MockHttpServl etResponse( ) ; 

BackupServl et backupServl et = new BackupServl et( ) ; 
backupServlet.doGet( request, response) ; 

String xmlContent = response. getContentAsString( ) ; 
assertTrue(xml Content . indexOf ( "<ti tl e>Backup Li st</ti tl e>" )>0) ; 



} 



Le code en grise, qui concentre 1' utilisation des simulacres, montre que Femploi de ces 
derniers est tres aise. Leur creation ne necessite aucun parametrage particulier, et toutes les 
methodes pour definir leur contenu puis le recuperer sont disponibles. 



Autres considerations sur les simulacres 

Pour terminer cette section consacree aux simulacres d'objets, il nous semble important 
d'insister sur deux points fondamentaux pour bien utiliser les simulacres : 

• Un cas de test portant sur un objet utilisant des simulacres ne doit pas tester ces derniers. 
L'objectif des simulacres est non pas d'etre testes, mais d'isoler un objet des contingences 
exterieures arm de faciliter sa verification. 

• Un simulacre doit etre concu de maniere a produire des donnees permettant de simuler 
l'ensemble du contrat de l'objet a tester. Ce contrat peut consister a retourner certaines 
donnees selon tel parametre, mais aussi a lancer une exception selon tel autre parametre. Le 
passage des tests ne demontre pas qu'un objet fonctionne correctement, mais seulement 
qu'il a su passer les tests. 

EasyMock repond a des besoins moyennement complexes en termes de simulacres. Pour des 
besoins plus complexes, il est conseille de developper specifiquement les simulacres sans 
l'aide d'un framework. 



En resume 

Comme pour les tests avec JUnit, les principes architecturaux de Spring facilitent la creation 
de simulacres. D'une part, la separation des interfaces et de leurs implementations permet 
d' utiliser nativement EasyMock sans passer par une extension permettant de realiser des 
simulacres a partir de classes. D'autre part, l'injection des dependances dans le composant 
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pouvant etre faite manuellement, done sans le conteneur leger, il est aise d'initialiser les colla- 
borateurs du composant a tester, non pas avec des implementations, mais avec des simulacres 
permettant de Fisoler des contingences exterieures. 

Les simulacres prets a l'emploi fournis par Spring sont tres utiles en ce qu'ils simulent des 
classes standards de l'API Java, tres utilisees dans les applications Java EE. 

Les tests d'integration 

JUnit et EasyMock suffisent dans la plupart des cas a realiser des tests unitaires. Les tests 
unitaires sont necessaires mais pas suffisants pour tester le bon fonctionnement d'une applica- 
tion. Les tests d'integration viennent en complement pour garantir que l'integration entre les 
composants de l'application s'effectue correctement. 

Dans cette section, nous allons mettre en place le test d'un DAO de Tudu Lists. Pour cela, 
nous utiliserons d'une part les extensions de Spring pour JUnit, afin de beneficier de l'injec- 
tion de dependances du conteneur leger, et d' autre pail le framework DbUnit pour initialiser 
le contenu de la base de donnees de tests. 

Les extensions de Spring pour JUnit 

Comme nous l'avons deja indique, JUnit peut etre utilise pour faire des tests unitaires aussi 
bien que des tests d'integration. C'est done tout a fait naturellement que Spring fournit des 
extensions a JUnit afin de pouvoir tester 1' integration des composants de l'application. Ces 
extensions ont pour vocation d'instancier le conteneur leger afin de beneficier de l'injection de 
dependances et de la POA. 

Ces extensions se presentent sous forme d' annotations, contenues dans le package 
org. springframework. test. context et ses sous-packages. Ces annotations font partie du 
Spring TestContext Framework, qui propose les fonctionnalites suivantes : 

• Chargement d'un contexte Spring pour chaque test. 

• Mise en cache automatique des contextes Spring partages entre plusieurs tests (accelerant 
ainsi l'execution globale des tests). 

• Injection de dependances dans les tests. 

• Possibilite d'ajout d'objets reagissant au cycle de vie des tests. 

Lutilisation d' annotations va dans le meme sens que JUnit 4.x et permet aussi une meilleure 
reutilisabilite des composants de tests, contrairement a l'heritage de classes de test. 



Spring et les versions de JUnit 

Spring 2.5 supporte JUnit dans sa version 4.4 mais pas dans sa version 4.5, cela a cause de change- 
ments dans l'API interne. JUnit 4.5 est en revanche supporte par Spring 3.0. Pour le developpeur de tests, 
il n'y a aucune difference, les deux versions de JUnit s'utilisent de la meme maniere. 
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Voici comment le test du DAO permettant de gerer les proprietes de Tudu Lists peut beneficier 
du support de Spring : 

package tudu. domain. dao.jpa; 

import org. j unit. runner. RunWith; 
import org. springframework. test .context 
import 

org.springf ramework. test .context. junit4 

@RunWith(SpringJUnit4Cl ass Runner. class) 
©ContextConf i gurati on 
public class PropertyDAOJpaTest { 
(...) 

} 

L' annotation ©RunWith est en fait une annotation JUnit qui indique au lanceur utilise de dele- 
guer l'execution du test a la classe de lanceur precisee en argument. Le SpringJUnit4- 
ClassRunner implemente ainsi toute la logique d'execution du framework de test de Spring. 
Utiliser ce lanceur n'ayant pas d'impact direct sur l'execution des tests, on lance toujours 
ceux-ci avec les moyens habituels (lanceurs texte de JUnit, Eclipse ou outils de construction). 

Le lanceur Spring va notamment extraire des informations de 1' annotation 
@ContextConfi gurati on. Celle-ci precise qu'un contexte Spring est necessaire au test et peut 
accepter des parametres precisant quels sont les fichiers definissant ce contexte. Si aucun 
parametre n'est passe a@ContextConfiguration, le nom du fichier de configuration sera deter- 
mine a partir du nom de la classe de test. Dans notre cas, la classe de test s'appelle 
tudu. domain. dao.jpa. PropertyDAOJpaTest et le contexte Spring sera charge a partir de 
cl asspath : /tudu. domain .dao.jpa . Property DAO JpaTest- con text .xml . 

Ce comportement par defaut est commode, mais nous preferons preciser les fichiers definissant le 
contexte de notre test. Ces fichiers seront au nombre de deux : 

• /tudu/conf/jpa-dao-context.xml : declare le contexte JPA et les DAO. II n'est pas auto- 
nome, car il necessite d'autres beans, notamment la connexion a la base de donnees (sous 
forme d'un DataSource) et l'adaptateur JPA. Ces deux beans ne sont pas directement 
declares dans ce fichier, car ils varient selon les environnements (tests d' integration ou utili- 
sation de F application en production). 

• /tudu/domain/dao/jpa/test-context.xml : complete le fichier precedent en definissant la 
connexion a la base de tests et l'adaptateur JPA (qui utilise Hibernate). II definit aussi une 
politique de transaction car pour les tests d' integration des DAO, en F absence de services 
metier, les transactions sont ramenees sur ceux-ci. 

Le fichier jpa-dao-context.xml est exactement le meme que celui defini dans la partie sur la 
persistance des donnees, car il fait partie des fichiers de configurations fixes de Tudu Lists. 
Voici l'essentiel du fichier test -context, xml : 

<bean id=" data Source" cl ass-" org.springf ramework. jdbc. da tasource. Si ngl e 
Connect i onDat a Source" 



.ContextConf i gurati on ; 
. Spri ngJUni t4Cl ass Runner; 
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<property name="driverClassName" value="org.hsqldb. jdbcDriver" /> 
<property name="url" value="jdbc:hsqldb:mem:tudu-test" /> 
<property name="username" value="sa" /> 
<property name="password" value="" /> 
<property name="suppressCl ose" value="true" /> 
</bean> 

<bean id=" j pa Vendor Adapter" class="org.springframework.orm. j pa. vendor. Hi be mate 
Jpa Vendor Ada pter"><—0 

<property name="showSql " val ue="f al se" /> 

<property name="generateDdl " value="true" /> 

<property name="databasePl atform" 
val ue="org.hibernate.dialect.HSQLDialect" /> 
</bean> 

<bean id=" trans act ionManager" 

class-" org. springf ramework.orm. jpa. JpaTransactionManager"><— Q 
<property 

name="enti tyManager Factory" 

ref="entityManagerFactory" /> 
</bean> 

<aop:config> 
<aop:pointcut 
id="dao" 

express ion="executi on (* tudu. domain .dao. jpa . .*DA0*.*( . .))"/> 
<aop:advisor advice-ref="txAdvice" pointcut-ref="dao"/> 
</aop:config> 

<tx: advi ce id="txAdvi ce" transact! on -manager="transactionManager"> 

<tx:attributes> 
<tx:method name="*" propagation="REQUIRED" /> 

</tx:attributes> 
</tx:advice> 

Le fichier commence par la definition de la connexion a la base de donnees sous la forme d'un 
DataSource, au repere Q. Cette definition est pailiculierement adaptee a une configuration de 
test : le DataSource ne cree qu'une connexion qui est reutilisee systematiquement, et la base de 
donnees est creee en memoire, il n'est done pas necessaire de disposer d'un serveur et de le 
lancer. 

L'adaptateur JPA est ensuite defini au repere Q. Une implementation Hibernate est utilisee, 
qui permet notamment de creer les tables a la volee. Cela se revele pailiculierement utile puis- 
que la base de donnees est en memoire et ne peut etre initialisee en-dehors de F execution du 
test. 

Enfin, la politique de transaction est definie au repere Q. II s'agit la d'une definition purement 
declarative, ramenant les transactions au niveau des DAO pour le besoin des tests. 
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II faut maintenant configurer le test unitaire pour qu'il utilise ces fichiers. Cela se fait en 
passant un tableau de chaines de caracteres au parametre locations de Fannotation 
©TestConfiguration : 

package tudu. domain. dao.jpa; 
import org. j unit. runner. RunWith; 

import org.springf ramework. test .context. ContextConf i gurat ion; 
import \ 

org.springf ramework. test. context. junit4. Spring J Unit4Cl ass Runner ; 

@RunWith(SpringJUnit4Cl ass Runner. class) 
©ContextConf i gurat ion (1 oca tions-{ 

"/tudu/domain/dao/jpa/test-context.xml " , 

"/tudu/conf /jpa-dao- context. xml " 

}) 

public class PropertyDAOJpaTest { 



Le contexte de note test va done s'initialiser parfaitement en reutilisant un fichier de configu- 
ration de 1' application et en le completant avec un fichier dedie aux tests d' integration des 



Le test va travailler sur le DAO gerant les proprietes, PropertyDAO. II faut done que cet objet 
soit une propriete du test. II suffit alors de declarer cette propriete dans le test et de faire en 
sorte qu'elle soit injectee. Linjection de dependances dans le test unitaire est bien sur prise en 
charge par le lanceur Spring. La concision etant de rigueur, nous utilisons l'annotation 
@Autowi red : 

package tudu. domain. dao.jpa; 
import org. j unit. runner. RunWith; 

import org. sp ringf ramework. beans. f actory . annotati on. Autowi red; 
import org.springf ramework. test .context. ContextConf i gurat ion; 
import \ 

org.springf ramework. test. context. junit4. Spring JUnit4Cl ass Runner ; 
import tudu.domain.dao. PropertyDAO; 

©RunWith (SpringJUnit4Cl ass Runner. class) 
©ContextConf i gurat ion (1 oca tions={ 

"/tudu/domain/dao/jpa/test-context.xml " , 

"/tudu/conf /jpa-dao -context. xml " 

}) 

public class PropertyDAOJpaTest { 
©Autowi red 

private PropertyDAO propertyDAO; 



(...) 



DAO. 



} 
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II est possible de tester rapidement l'initialisation de notre test en verifiant que le chargement 
se fait correctement et en s'assurant que le DAO a ete injecte. II suffit d'ajouter la methode de 
test suivante : 

©Test 

publ i c void ini tOK( ) { 

Assert. assertNotNull (propertyDAO) ; 

} 

II est clair que cette methode ne teste pas le DAO, mais elle a le merite de nous renseigner sur 
notre avancement. 

Nous venons de voir comment Spring peut nous aider dans l'initialisation des tests d'integra- 
tion. C'est dans ces tests que le conteneur Spring prend toute son ampleur, car il nous permet 
d'elaborer tres finement notre configuration de test. 

L'apport de Spring ne s'arrete pas la: avec seulement quelques annotations, le contexte 
Spring est automatiquement charge (et mis en cache), et le test peut se voir injecter les depen- 
dances dont il a besoin. L'etape suivante consiste a tester proprement dit le DAO, mais cela 
necessite des manipulations avec la base de donnees et c'est la qu'intervient DbUnit. 



Utilisation de DbUnit avec Spring 

DbUnit est une extension de JUnit facilitant les tests effectuant des operations en base de 
donnees. DbUnit supporte la plupart des bases de donnees. Ce framework est disponible a 
F adresse http://dbunit. sourceforge. net/. 

DbUnit permet de mettre dans un etat connu une base de donnees avant d'effectuer un test. 
Ce raisonnement plutot simple est en effet le meilleur moyen d'eviter les problemes d'initiali- 
sation et de corruption des donnees lors de F execution de tests sur une base. 

DbUnit sera d'autant plus facile a integrer dans une infrastructure de tests si une approche 
agile est adoptee. Voici done un ensemble de bonnes pratiques pour les tests mettant en jeu 
une base de donnees : 

• Une instance de base de donnees par developpeur. Chaque developpeur doit disposer de sa 
propre instance de base de donnees. L'idee est que chaque developpeur peut effectuer ses 
tests sans perturber les autres. L'instance peut se trouver sur la machine du developpeur. En 
effet, la plupart des bases gratuites sont simples a installer et peu consommatrices en 
ressources. La plupart des bases de donnees payantes proposent une edition pour le deve- 
loppement (Oracle propose par exemple Oracle Express Edition). II est aussi possible de 
creer autant d'instances de tests qu'il y a de developpeurs sur un serveur central. 

• Utiliser des jeux de donnees minimalistes. Les donnees doivent seulement permettre de 
tester toutes les eventualites, pas de mesurer la rapidite d' execution. II est done preferable 
de remplir les tables avec au maximum quelques dizaines d'enregistrements, et ce arm que 
les tests s'executent le plus rapidement possible. L'optimisation des requetes (jointures, 
index) doit plutot etre faite avec de veritables donnees, bien que la question des perfor- 
mances doive toujours etre a F esprit des developpeurs ! 
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• Tous les tests doivent etre independants. II ne faut pas qu'un test depende des donnees d'un 
autre test. Chaque test doit done avoir son propre jeu de donnees, et aucune autre phase 
d'initialisation des donnees ne doit etre necessaire. 

Au cceur de DbUnit se trouve la notion de jeu de donnees (dataset, qui correspond a Finter- 
face org. dbunit. dataset. IDataSet). DbUnit synchronise la base de donnees a partir d'imple- 
mentations de IDataSet. La maniere la plus commune de creer un jeu de donnees est d'ecrire 
un fichier XML et de laisser DbUnit creer l'objet correspondant. 

Prenons, par exemple, la table contenant les proprietes de F application Tudu Lists. Les anno- 
tations JPA posees sur Fentite nous indiquent que la table s'appelle property et que la 
propriete key correspond au champ pkey. La propriete value est automatiquement mise en 
correspondance avec la colonne de meme nom. Voici le fichier XML correspondant : 

<?xml version='1.0' encoding='UTF-8'?> 
<dataset> 

<property pkey="smtp.host" value="some.url .com" /> 
</dataset> 

Ce format est appele « plat » (flat) dans la nomenclature des IDataSet de DbUnit. On remar- 
que qu'au nom de la table correspond le nom de la balise et qu'aux proprietes correspondent 
les attributs de la balise. Chaque balise property correspond a un enregistrement dans la table 
correspondante. 

Si ce fichier s'appelle property. xml, le code suivant permet de charger ce fichier sous forme 
de IDataSet : 

IDataSet dataSet = new Fl atXml DataSet(new Fi 1 e( "property .xml ")) ; 

A partir d'un objet IDataSet, il est possible de compter le nombre d'enregistrements de 
chacune des tables, de recuperer les valeurs pour chaque colonne de chaque enregistrement 
de chaque table, etc. L operation qio nous interesse consiste a mettre le contenu du jeu de 
donnees dans notre base. L'insertion doit passer par une connexion JDBC ou un DataSource. 
La plupart de nos composants utilisant un DataSource, nous optons pour cette solution. 

Voici un exemple de code pour effectuer l'insertion de notre jeu de donnees : 
import javax. sql . DataSource;*— Q 

import org. dbun i t. database. Da t a baseDataSourceConnect ion; 

import org. dbun it. dataset. IDataSet; 

import org. dbunit. dataset. xml . Fl atXml DataSet ; 

import org. dbun i t. opera t ion. Da t aba seOperat ion; 



(...) 



IDataSet dataSet = new Fl atXml DataSet( 



new FileCproperty.xml ") 
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II recuperation du DataSource 
(...) 

DatabaseDataSourceConnecti on datasourceConnection = 
new DatabaseDataSourceConnection( 
dataSource 

);<-0 

Da tabaseOpe rati on . CLEAN_INSERT. execute ( 

datasourceConnection , 

dataSet 
);<-& 

II faut dans un premier temps effectuer un ensemble d' imports de packages, principalement de 
DbUnit (Q). 

Le repere© reprend la creation du IDataSet. Nous initialisons ensuite le DataSource (©). 
Cette partie n'est pas detaillee pour F instant (Spring nous permettra de combler cette lacune 
par la suite). II faut ensuite creer une connexion telle que F attend DbUnit, et ce a partir du 
DataSource. C'est ce qui est effectue aurepere Q, en utilisant DatabaseDataSourceConnecti on, 
qui fait partie de FAPI DbUnit. 

Le repere 0 constitue la partie la plus interessante de notre exemple. C'est la que s'effectue 
Finjection du jeu de donnees dans la base de donnees. Pour cela, un appel statique sur 
DatabaseOperati on nous perniet d'effectuer une insertion « propre » (clean insert). Dans notre 
cas, cela consistera a vider la table property et a la remplir avec les enregistrements decrits 
dans le fichier XML. L operation de clean insert est F operation d'injection de donnees par 
defaut effectuee par DbUnit : elle vide toute table impliquee dans le jeu de donnees. 

DbUnit propose une API tres riche et des fonctionnalites plus interessantes les unes que les 
autres, mais nous avons vu la Fessentiel qui nous interesse. L'idee est maintenant d'effectuer 
cette injection de donnees juste avant nos methodes de test. Le code precedent a done sa place 
dans une methode annotee avec ©Before afin d'etre executee avant chaque methode de test. 
Reprenons notre test unitaire ou nous F avons laisse : 

package tudu. domain. dao.jpa; 
(...) 

@RunWith(SpringJUnit4ClassRunner. class) 
©ContextConf igurationd ocations-{ 

"/tudu/domai n/dao/j pa /test -context .xml " , 

"/tudu/conf /jpa-dao-context .xml " 

}) 

public class PropertyDAOJpaTest { 
@Autowi red 

private PropertyDAO propertyDAO; 
@Autowi red 

private DataSource dataSource 
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©Before 

publ ic void setUp( ) { 

IDataSet dataSet = new Fl atXml DataSet( 
new Fil e( "property .xml " ) 

); 

DatabaseOpe rati on . CLEAN_I NS ERT. execute ( 

new DatabaseDataSourceConnection(dataSource) . 
dataSet 

); 

} 

©Test 

public void getPropertyOK( ) { 

Property prop = propertyDAO. getProperty( "smtp. host" ) ; 
Assert. assertNotNul 1 (prop) ; 

Assert . assert Equal s( "smtp. host" , prop. get Key ( ) ) ; 
Assert . assert Equal s( "some.url .com" .prop.getVal ue( ) ) ; 

} 

(...) 

} 

Cette methode d'initialisation s'integre parfaitement avec le fonctionnement de nos tests 
d' integration, rendant Futilisation de DbUnit tres facile. L'exemple montre aussi le test de la 
methode getProperty pour une cle existant en base. Malgre son aspect plutot simple, rendu 
possible notamment par le support JUnit de Spring, ce test nous assure que le fichier de confi- 
guration des DAO de Tudu Lists est correct et que la methode getProperty fonctionne correc- 
tement. 

II est aussi possible de tester un autre contrat de notre methode, celui qui consiste a dire 
qu'elle renvoie un objet nul si la cle n'existe pas en base : 

@Test 

public void getPropertyNOK( ) { 

Property prop = propertyDAO. getProperty( "some. dummy . key" ) ; 
Assert . assert Nul 1 (prop) ; 

} 

Ce test parait anodin, mais renvoyer une exception serait un comportement tout aussi possible. 
Un quelconque changement de comportement sera done immediatement detecte grace a ce 
test. 

Deux autres methodes sont a tester dans le DAO : saveProperty et updateProperty. DbUnit est 
encore d'une aide precieuse pour s'assurer du bon deroulement des methodes. Voici le test 
pour la methode saveProperty : 

@Test 

public void saveProperty( ) throws Exception { 
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Property toSave = new PropertyO; 
toSave.setKeyC'some.key") ; 
toSave.setVal ue( "some. val ue" ) ;<— O 
propertyDAO. saveProperty (toSave) ;<— © 
DatabaseDataSourceConnection dsConnecti on = 

new DatabaseDataSourceConnection( 
dataSource 

);<-© 

IDataSet databaseDataSet = dsConnection.createDataSet( ) ;<— © 
ITable tabl ePersonne = databaseDataSet . getTabl e( "property" ) ;<— © 
assert Equal s(2,tabl ePersonne. get RowCount( ) ) ;<— © 

} 

Le test commence par la creation de l'objet propriete a persister (©). Au repere ©, la 
methode a tester est appelee. II faut ensuite, comme pour l'injection du jeu de donnees, 
travailler avec FAPI de DbUnit. Cela passe par la creation de la connexion DbUnit, via le 
DataSource (injecte dans le test par Spring), au repere ©. L'objet de connexion permet de 
creer un IDataSet a partir du contenu de la base de donnees (©). A partir de ce IDataSet, il est 
possible de recuperer la table qui nous interesse (©) et de connaitre le nombre d'enregistre- 
ments dans cette table ann d'effectuer une verification (©). Notre jeu de donnees XML injec- 
tant une seule ligne dans la table property, il faut qu'il y ait deux enregistrements apres l'appel 
a la methode saveProperty. DbUnit pourrait nous permettre de pousser plus loin nos verifica- 
tions en allant jusqu'a verifier les valeurs des colonnes pour chacun des enregistrements. Nous 
n'irons pas jusque-la, la verification du nombre d' enregistrements dans la table etant suffi- 
sante. 

L ensemble de ces verifications permet de tester efficacement notre DAO ; cependant, les 
appels a FAPI DbUnit sont un peu fastidieux. Tudu Lists contient done une classe utilitaire 
permettant de faire rapidement les operations les plus courantes (injection d'un jeu de 
donnees, recuperation du nombre d' enregistrements dans une table, etc.). Cette classe 
s'appelle DbUnitHelper ; elle necessite seulement un DataSource comme dependance. UnBean 
dbUnitHelper est declare dans le contexte Spring. Nous ne detaillerons pas F implementation 
de cette classe, qui encapsule des appels basiques mais quelque peu verbeux a FAPI DbUnit. 
Cette classe peut aussi etre utilisee dans la methode setup arm d'effectuer l'injection du jeu de 
donnees. 

Voici maintenant l'apparence de notre test unitaire : 
(...) 

public class PropertyDAOJpaTest { 
@Autowi red 

private PropertyDAO propertyDAO; 
@Autowi red 

private DbUnitHelper helper; 
©Before 

public void setUpO throws Exception { 
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IDataSet dataSet = new Fl atXml DataSet( "property .xml ") ; 
hel per. doClean Insert (data Set) ; 

} 

©Test 

public void saveProperty( ) throws Exception { 
Property toSave = new PropertyO; 
toSave.setKeyCsome.key") ; 
toSave. setVal ue( "some. val ue" ) ; 
property DAO. saveProperty (toSave) ; 

assert Equal s(2,hel per . getTabl e( "property" ) .getRowCount( ) ) ; 

} 

} 

L'utilisation du DbUni tHel per rend le test unitaire un peu moins verbeux et moins tributaire de 
DbUnit. 

Le test de la methode updateProperty est lui aussi tres simple : 
@Test 

public void updateProperty ( ) throws Exception { 
Property toUpdate = new PropertyO; 
toLlpda te. set Key ( "smtp. host" ) ; 
toUpdate. setVal ue( "some. other . host" ) ; 
property DAO. updateProperty (toUpdate) ; 
ITable table = hel per .getTabl e( "property" ) ; 
Assert . assert Equal s( 
"some. other. host", 

tabl e.getVal ue(0, "val ue" ) . toString( ) 

); 



En resume 

Les tests d' integration utilisant JUnit sont facilites pour les applications qui utilisent Spring. 
Le Spring TestContext Framework permet d'ajouter du comportement aux classes de tests 
unitaires. II gere alors le chargement du contexte Spring, sa mise en cache s'il est partage par 
plusieurs classes de tests et l'injection de dependances dans le test unitaire. 

Toutes ces fonctionnalites permettent de recreer un contexte d' execution pour les tests 
d'integration. Une division judicieuse des fichiers Spring permet de reutiliser ceux-ci pour 
differents environnements. Les tests des DAO de Tudu Lists travaillent ainsi sur une base 
de donnees en memoire, sans que le fichier de definition des DAO n'ait eu a subir de modi- 
fications. 

La puissance du conteneur leger Spring permet d'integrer elegamment DbUnit. II est alors tres 
aise de mettre la base de donnees dans un etat adapte pour tous les tests et done de tester de 
facon fiable tout composant interagissant avec la base de donnees. 
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Reagir a I'execution des tests 

Le Spring TestContext Framework propose un systeme d'ecouteur a I'execution des classes 
de tests. C'est par ce biais que l'injection de dependances dans un test est possible. Ce 
mecanisme tres puissant permet d'ajouter facilement du comportement « autour » de 
I'execution des tests. L'impact sur la classe de test unitaire est minime, et seul l'ajout 
d'une annotation parametree correctement est necessaire (pas d'heritage ou d'interface a 
implementer). 

Voici la definition de F interface d'ecouteur : 
package org. springframework. test .context; 

public interface TestExecutionListener { 

void prepareTestlnstancedestContext testCtx) throws Exception; 

void beforeTestMethoddestContext testCtx) throws Exception; 

void afterTestMethoddestContext testCtx) throws Exception; 

} 

Les methodes sont executees suite a la creation de l'objet de test puis avant et apres chaque 
methode de test. 

Chaque test dispose de sa propre pile d'ecouteurs. II est possible de la parameter avec l'anno- 
tation org. springframework. test. context. TestExecutionListeners a laquelle on passe un 
tableau de TestExecutionListeners : 

@RunWith(SpringJUnit4ClassRunner. class) 
©ContextConf i gurati on 

©Tes t Execution Li steners( { MyTest Execution Li stener.cl ass} ) 
public class MyTest { 
(...) 

} 

L' annotation ©Test Execution Listeners ne peut evidemment fonctionner que si les annotations 
©Runwith et ©ContextConfi gurati on sont positionnees. Si l'annotation ©TestExe- 
cutionListeners n'est pas positionnee, l'ecouteur d'injection de dependances (fourni par 
Spring) est positionne par defaut. Cette annotation n'est done a utiliser que dans le cas ou Ton 
souhaite positionner ces propres ecouteurs. 

Ce principe d'ecouteur peut sembler bien complexe et surtout redondant compte tenu de 
l'existence du systeme d'annotations JUnit reagissant a I'execution du test (©Before et 
©After). Son utilite est toutefois justifiee par sa plus grande reutilisabilite. Un ecouteur peut 
encapsuler un code complexe qui alourdirait un test si ce code apparaissait directement dans 
une methode annotee avec ©Before ou ©After. Une fois l'ecouteur code, il peut ete ajoute 
simplement via l'annotation ©TestExecutionListeners, ce qui est tres peu intrusif. 
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Nous allons illustrer l'ecriture d'un ecouteur par l'amelioration de notre infrastructure de test 
d' integration. Nous avons precedemment effectue l'injection d'un jeu de donnees en base de 
donnees dans une methode annotee avec ©Before. Cela convenait parfaitement au test de notre 
DAO. Mais imaginons que nous voulions tester d'autres composants interagissant avec la base 
de donnees. Le test de ces composants necessiterait aussi d' avoir une base de donnees dans un 
etat connu, et cela passerait bien evidemment par DbUnit. 

Ce besoin de reutilisabilite nous conduit a penser que l'ecriture d'un TestExecutionListener 
serait tout a fait adaptee. Cet ecouteur serait positionne sur des tests qui precisent un jeu de 
donnees a injecter. Nous pouvons, par exemple, definir une interface que ces tests devraient 
implementer pour localiser le fichier XML de ce jeu de donnees : 

public interface DataSetLocator { 
public String getDataSet( ) ; 

} 

L'interface DataSetLocator definit (sous la forme d'une chaine de caracteres) la localisation 
du IDataSet. Nous aurions pu definir une annotation ou adopter un fonctionnement par defaut 
(localiser le fichier XML en fonction du nom de la classe de test), mais cette approche par 
interface nous semble un bon compromis. 

Nous pouvons definir l'ecouteur effectuant l'injection de la maniere suivante : 
(...) 

public class CleanlnsertTestExecutionListener 
implements TestExecutionListener { 

public void beforeTestMethoddestContext ctx) throws Exception { 
if (ctx.getTestInstance( ) instanceof DataSetLocator) {<— O 
DataSetLocator test = (DataSetLocator) ctx.getTestlnstancet ) ; 
ApplicationContext appCtx = ctx.getAppl icationContext( ) ; 
DbUnitHelper helper = null; 
if (appCtx. con tains Bean( "dbLlnitHel per" ) ) { 

helper = (DbUnitHelper) appCtx. getBean( "dbUnitHel per" ) ; 
} else { 

DataSource ds = (DataSource) appCtx. getBean( "dataSource" ) ; 
helper - new DbUnitHelper(ds) ; 

IDataSet dataSet = hel per .getDataSet(test .getDataSet( ) ) ;<— Q 
hel per. doClean Insert (data Set) ;<— Q 

} 

} 

public void prepareTestlnstancedestContext ctx) throws Exception 
{ 

// aucune operation<— Q 

} 
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public void afterTestMethod(TestContext ctx) throws Exception { 
// aucune operation<— Q 

} 

} 

L'injection du jeu de donnees se fait avant chaque methode de test : c'est pourquoi la methode 
beforeTestMethod est implementee. Celle-ci verifie que le test unitaire implemente bien 
Finterface DataSetLocator afin de pouvoir localiser le jeu de donnees (©). Le code precedant 
le repere Q permet de disposer d'un DbUnitHelper, soit en le recuperant dans le contexte 
Spring, soit en en creant un en utilisant le DataSource. Le jeu de donnees est ensuite cree a 
partir de 1' information donnee par le test (©), puis injecte dans la base de donnees (©). 
Le DbUnitHelper nous assiste bien dans toutes ces taches. 

Les deux autres methodes de l'interface TestExecutionListener n'ayant pas d'utilite dans 
notre cas, elles ont une implementation vide (©, ©). 

Voici maintenant le test unitaire du DAO propriete : 

@Runwith(SpringJUnit4ClassRunner. class) 
©ContextConf igurationd ocations={ 

"/tudu/domain/dao/jpa/test-context.xml " , 

"/tudu/conf /j pa- dao- context .xml " 

}) 

@Tes t Execution Li steners{ 

CI ean I nsertTest Execution Li stener .cl ass ,<— O 
Dependency In jectionTest Execution Li stener . cl ass<— © 

}) 

public class PropertyDAOJpaTest implements DataSetLocator { 
(...) 

public String getDataSetO { 

return "/tudu/domain/dao/dataset/property .xml " ;<— © 

} 

} 

La methode setup, effectuant l'injection du jeu de donnees, n'est plus necessaire. Le test 
unitaire definit dans sa pile d'ecouteurs non seulement l'ecouteur effectuant l'injection de 
donnees (©), mais aussi celui faisant l'injection de dependances (©). Celui-ci est positionne 
par defaut en l'absence de l'annotation ©TestExecutionListeners, mais il n'est pas ajoute 
automatiquement si Ton precise sa propre pile. 

Enfin, le test unitaire implementant l'interface DataSetLocator definit la methode getDataSet, 
qui doit retourner la localisation du jeu de donnees au format XML plat de DbUnit (©). 

Cette plongee dans les mecanismes du Spring TestContext Framework nous a permis d'ecrire 
un composant facilement reutilisable pour l'injection de donnees en base de donnees. Cette 
approche est particulierement elegante pour integrer des composants tels que DbUnit et ajouter 
du comportement de fa5on completement transversale a des tests unitaires. 
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Conclusion 

Ce chapitre a montre comment tester une application Spring avec JUnit. Du point de vue des 
tests unitaires, le code fonde sur Spring ne necessite pas d' extension particuliere a JUnit, 
hormis F utilisation le cas echeant d'un framework specifique, comme EasyMock, pour simuler 
les objets dont depend le composant a tester. 

Spring fournit par ailleurs des simulacres prets a l'emploi pour certains composants techni- 
ques de l'API Java EE. Pour les tests unitaires, seul le code applicatif est utilise, sans l'aide du 
conteneur leger de Spring. L' injection des dependances est effectuee manuellement dans les 
tests. 

Pour les tests d' integration, JUnit necessite plusieurs extensions, car, dans ce cas, le conteneur 
leger doit etre utilise. A cette fin, Spring fournit le TestContext Framework qui se charge de la 
gestion du contexte des tests. Un utilitaire tel que DbUnit peut alors facilement etre integre 
pour tester, par exemple, les composants interagissant avec la base de donnees. 
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Les frameworks 
de presentation 

Cette partie se penche sur les principes mis en ceuvre par Spring afin de resoudre les preoc- 
cupations liees aux applications Web. Spring couvre un large spectre de technologies Web, 
allant des servlets a Ajax, et s'efforce de preserver l'homogeneite de ses differents supports 
Web en utilisant des mecanismes similaires. 

Spring et son portfolio proposent un ensemble de frameworks adressant notamment le 
patron de conception MVC lui-meme, ainsi que les Hots de traitement Web. En parallele, 
des integrations sont mises a disposition par des outils externes afin d' aider a traiter les 
problematiques liees a Ajax. 

Le chapitre 7 traite de Spring MVC, le framework MVC de Spring. Ce dernier fournit un 
cadre souple et robuste afin d'implementer des applications Web fondees sur la technologie 
servlet. II tire un parti maximal des fonctionnalites du conteneur leger de Spring et fournit 
un interessant modele de programmation fonde sur les annotations. 

Le chapitre 8 est consacre a Spring Web Flow, un framework de gestion des Hots Web qui 
offre de puissants mecanismes afin de configurer et controler les enchainements de pages 
dans les applications Web. 

Le chapitre 9 clot cette partie en abordant la mise en ceuvre d'approches AJAX avec les 
outils DWR et GWT, ces derniers permettant de mettre en ceuvre des applications Web 
riches a l'interface graphique plus elaboree que les applications Web classiques. 
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La mise en pratique du patron de conception MVC (Model View Controller) offre une 
meilleure structuration du tiers de presentation des applications Java EE en dissociant les 
preoccupations de declenchement des traitements de la construction de la presentation propre- 
ment dite. Les principaux frameworks MVC implemented le type 2 de ce patron, qui instaure 
un point d' entree unique ay ant pour mission d'aiguiller les requetes vers la bonne entite de 
traitement. 

Le framework Spring offre une implementation innovante du patron MVC par le biais d'un 
framework nomme Spring MVC, qui profite des avantages de l'injection de dependances (voir 
chapitres 2 et 3) et qui, depuis la version 2.5, offre une interessante flexibilite grace aux anno- 
tations Java 5. Ce module permet des lors de s'abstraire de l'API Servlet de Java EE, les infor- 
mations souhaitees etant automatiquement mises a disposition en tant que parametres des 
methodes des controleurs. 

De plus, a partir de la version 3.0, Spring MVC integre un support permettant de gerer la tech- 
nologie REST, les URL possedant la structure decrite par cette derniere etant exploitable en 
natif. 

Le present chapitre passe en revue les fonctionnalites et apports de ce module, qui met en 
ceuvre les principes generaux du framework Spring, lesquels consistent a masquer l'API 
Servlet et a simplifier les developpements d' applications Java EE tout en favorisant leur struc- 
turation et leur flexibilite. 

Implementation du pattern MVC de type 2 dans Spring 

Cette section decrit brievement 1' implementation du patron de conception MVC de type 2 
dans le framework Spring. 
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Nous presenterons rapidement les concepts de base du type 2 de ce patron puis nous concen- 
trerons sur les principes de fonctionnement et constituants de Spring MVC, F implementation 
du patron MVC par Spring. 

Fonctionnement du patron MVC 2 

Le patron MVC est communement utilise dans les applications Java/Java EE pour realiser la 
couche de presentation des donnees aussi bien dans les applications Web que pour les clients 
lourds. Lorsqu'il est utilise dans le cadre de Java EE, il s'appuie generalement sur FAPI 
servlet ainsi que sur des technologies telles que JSP/JSTL. 

II existe deux types de patrons MVC, celui dit de type 1, qui possede un controleur par action, 
et celui dit de type 2, plus recent et plus flexible, qui possede un controleur unique. Nous nous 
concentrerons sur ce dernier, puisqu'il est implemente dans les frameworks MVC. 

La figure 7-1 illustre les differentes entites du type 2 du patron MVC ainsi que leurs interactions 
lors du traitement d'une requete. 



Controleur 



Controleur frontal 



Aiguillage des 
requetes vers la 
bonne entite de 
traitement 



Entite de traitement 



Realise les 
traitements de la 
requete 



i 



Vue 



Fichier 



Construite la vue 
avec un pseudo 
template afin 
d'affioher les 
donnees a presenter 



Classe 



Construit la vue en 
Java afin d'affioher 
les donnees a 
presenter 



Modele 
Objet 

Contient les 
donnees a 
presenter 

I 

J" " • 

I 



Figure 7-1 

Entites mises en ceuvre dans le patron MVC de type 2 
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Les caracteristiques des composants mis en ceuvre dans ce patron sont les suivantes : 

• Modele. Permet de mettre a disposition les informations utilisees par la suite lors des trai- 
tements de presentation. Cette entite est independante des API techniques et est constitute 
uniquement de Beans Java. 

• Vue. Permet la presentation des donnees du modele. II existe plusieurs technologies de 
presentation, parmi lesquelles JSP/JSTL, XML, les moteurs de templates Velocity et Free- 
Marker ou de simples classes Java pouvant generer differents types de formats. 

• Controleur. Gere les interactions avec le client tout en declenchant les traitements appro- 
pries. Cette entite interagit directement avec les composants de la couche service metier et 
a pour responsabilite la recuperation des donnees mises a disposition dans le modele. Lors 
de la mise en ceuvre du type 2 de ce patron, cette partie se compose d'un point d' entree 
unique pour toute l'application et de plusieurs entites de traitement. Ce point d'entree 
unique traite la requete et dirige les traitements vers l'entite appropriee. Pour cette raison, 
1' entite de traitement est habituellement appelee controleur. Le controleur frontal, ou 
« controleur facade », est integre au framework MVC, et seuls les entites de traitement sont 
specifiques a l'application. 

Un framework MVC implemente le controleur facade, les mecanismes de gestion du modele, 
ainsi que ceux de selection et de construction de la vue. Lutilisateur d'un tel framework a en 
charge le developpement et la configuration des entites de traitements et des vues choisies. 

Principes et composants de Spring MVC 

Le framework Spring fournit des integrations avec les principaux frameworks MVC ainsi que 
sa propre implementation. Forts de leur experience dans le developpement d' applications Java 
EE, ses concepteurs considerent que l'injection de dependances offre un apport de taille pour 
concevoir et structurer des applications fondees sur le patron MVC. 

Precisons que Spring MVC ne constitue qu'une partie du support relatif aux applications Web. 
Le framework Spring offre d'autres fonctionnalites permettant notamment le chargement des 
contextes applicatifs de maniere transparente ainsi que des integrations avec d'autres 
frameworks MVC, tels JSF, Web Work ou Tapestry. 

Parmi les principes fondateurs de Spring MVC, remarquons notamment les suivants : 

• Utilisation du conteneur leger arm de configurer les differentes entites du patron MVC et de 
beneficier de toutes les fonctionnalites du framework Spring, notamment au niveau de la 
resolution des dependances. 

• Favorisation de la flexibilite et du decouplage des differentes entites mises en ceuvre grace 
a la programmation par interface. 

• Utilisation d'une hierarchie de contextes applicatifs arm de realiser une separation logique 
des differents composants de l'application. Par exemple, les composants des services 
metier et des couches inferieures n'ont pas acces a ceux du MVC. 
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Les composants du MVC ont pour leur part les principales caracteristiques suivantes : 

• A partir de la version 2.5 de Spring, la gestion de Faiguillage et la configuration des contro- 
leurs MVC se realisent par l'intermediaire d' annotations. Par ce biais, Spring MVC permet 
de masquer 1' utilisation de F API servlet et favorise la mise en ceuvre des tests unitaires a ce 
niveau. L'approche fondee sur les classes d' implementation de controleurs est desormais 
depreciee. 

• Gestion des formulaires en se fondant sur les annotations relatives aux controleurs afin non 
seulement de charger et d'afficher les donnees du formulaire, mais egalement de gerer leur 
soumission. Ces donnees sont utilisees pour remplir directement un Bean sans lien avec 
Spring MVC, qui peut etre valide si necessaire. Des mecanismes de mappage et de conversion 
des donnees sont integres et extensibles selon les besoins. 

• Abstraction de F implementation des vues par rapport aux controleurs permettant de 
changer de technologie de presentation sans impacter le controleur. 

Pour mettre en ceuvre ces principes et composants, Spring MVC s'appuie sur les entites illus- 
trees a la figure 7-2. Le traitement d'une requete passe successivement par les differentes entites 
en commencant par la servlet Di spatcherServl et et en finissant par la vue choisie. 
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Figure 7-2 

Entites de traitement des requetes de Spring MVC 



Les principaux composants de Spring MVC peuvent etre repartis en trois groupes, selon leur 
fonction : 

• Gestion du controleur fa5ade et des contextes applicatifs. Permet de specifier les fichiers des 
differents contextes ainsi que leurs chargements. Le controleur fa?ade doit etre configure de 
fa5on a specifier Faeces a I'application. 
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• Gestion des controleurs. Consiste a configurer la strategie d'acces aux controleurs, ainsi 
que leurs differentes classes d' implementation et leurs proprietes. L'aiguillage se configure 
desormais directement dans les classes mettant en ceuvre des controleurs en se fondant sur 
des annotations. Ces dernieres permettent egalement de mettre facilement a disposition les 
donnees presentes dans la requete, la session et le modele. 

• Gestion des vues. Consiste a configurer la ou les strategies de resolution des vues ainsi que 
les frameworks ou technologies de vue mis en ceuvre. 



Initialisation du framework Spring MVC 

L'initialisation du framework Spring MVC s'effectue en deux parties, essentiellement au sein 
du fichier web.xml puisqu'elle utilise des mecanismes de la specification Java EE servlet. 

Gestion des contextes 

Le framework Spring permet de charger automatiquement les contextes applicatifs en utilisant 
les mecanismes des conteneurs de servlets. 

Dans le cadre d' applications Java EE, une hierarchie de contextes est mise en ceuvre afin de 
regrouper et d'isoler de maniere logique les differents composants. De la sorte, un composant 
d'une couche ne peut acceder a celui d'une couche superieure. 



Contexte applicatif Spring 

Rappelons qu'un contexte applicatif correspond au conteneur leger en lui-meme, dont la fonction est de 
gerer des Beans. Le framework offre egalement un mecanisme permettant de definir une hierarchie de 
contextes afin de realiser une separation logique entre des groupes de Beans. Dans le cas du MVC, il 
s'agit d'empecher I'utilisation de composants du MVC par des composants service metier ou d'acces 
aux donnees. 



Le framework Spring offre une hierarchie pour les trois contextes suivants : 

• Contexte racine. Ce contexte est tres utile pour partager des objets d'une meme biblio- 
theque entre plusieurs modules d'une meme application Java EE pour un meme chargeur de 
classes. 

• Contexte de 1' application Web. Stocke dans le ServletContext, ce contexte doit contenir la 
logique metier ainsi que celle de Faeces aux donnees. 

• Contexte du framework MVC. Gere par le controleur facade du framework, ce contexte doit 
contenir tous les composants relatifs au framework MVC utilise. 
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La figure 7-3 illustre cette hierarchic ainsi que la portee des differents contextes. 
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La mise en ceuvre du contexte de 1' application Web est obligatoire, tandis que celle du 
contexte racine est optionnelle et n'est done pas detaillee ici. Si ce dernier est omis, 
Spring positionne de maniere transparente celui de 1' application Web en tant que contexte 
racine. 

L initialisation du contexte de F application Web, que nous detaillons dans ce chapitre, est 
independante du framework MVC choisi et utilise les mecanismes du conteneur de servlets. 
Sa configuration est identique dans le cadre du support d'autres frameworks MVC. 



Chargement du contexte de I'application Web 

Le framework Spring fournit une implementation de la classe ServletContextListener de la 
specification servlet permettant de configurer et d'initialiser ce contexte au demarrage et de le 
finaliser a F arret de I'application Web. 

Cette fonctionnalite est utilisable avec un conteneur de servlets supportant au moins la 
version 2.3 de la specification. Cet observateur parametre les fichiers de configuration XML 
du contexte en ajoutant les lignes suivantes dans le fichier web.xml de I'application : 

<context-param> 

<param-name>contextConf igLocation</param-name> 
<param-val ue>/WEB- INF/appl icationContext*.xml </param-val ue> 
</context-param> 

<1 i stener> 

<listener-class> 

org.sprirgf ramework. web. context .Context Loader Listener 
</l i stener-cl ass> 
</l 1 stener> 
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Chargement du contexte de Spring MVC 

La configuration tout comme le chargement de ce contexte sont lies a ceux de la servlet du 
controleur facade de Spring MVC. Precisons que, par defaut, cette derniere initialise un 
contexte applicatif fonde sur un fichier <nom-servlet>-servlet.xml, lequel utilise le nom de la 
servlet precedente pour <nom-servl et>. Ce fichier se situe par defaut dans le repertoire WEB- 
INF ; la valeur de <nom-servl et> est specifiee grace a la balise servl et-name. 

Dans notre etude de cas, la servlet de Spring MVC s'appelle tudu. Le fichier tudu-servlet.xml 
contient les differents composants utilises par ce framework, comme les controleurs, les vues 
et les entites de resolution des requetes et des vues. 

Nous pouvons personnaliser le nom de ce fichier a l'aide du parametre d'initialisation 
contextConfigLocation de la servlet. Le code suivant montre comment specifier un fichier 
mvc-context.xml pour le contexte de Spring MVC par F intermediate du parametre prece- 
demment cite (Q) : 

<web-app> 
(...) 
<servl et> 

<servl et-name>tudu</servl et-name> 
(...) 

<init-param><— Q 

<param-name>contextConf igLocation</param-name> 
<param-val ue>/WEB- I NF/mvc- context .xml </param-val ue> 
</init-param> 
</servl et> 
</web-app> 

Initialisation du controleur fagade 

Le fait que le framework Spring MVC implemente le patron MVC de type 2 entraine qu'il 
met en ceuvre un controleur facade pour diriger les traitements vers des classes designees par 
le terme Controller dans Spring MVC. 



Le controleur fagade 

Cette entite correspond a I'unique point d'acces de I'application Web. Son role est de rediriger les traite- 
ments vers le bon controleur en se fondant sur I'adresse d'acces pour traiter la requete. Dans le cas 
d'applications Web, ce controleur est implemente par le biais d'une servlet, qui est generalement fournie 
par le framework MVC utilise. 



Ce controleur facade est implemente par le biais de la servlet DispatcherServlet du package 
org . spri ngf ramework.web . servl et, cette derniere devant etre configuree dans le fichier WEB- 
INF/web.xml. 

Le mappage de la ressource (Q) est defini au niveau du conteneur de servlets dans le fichier 
web.xml localise dans le repertoire WEB-INF. Spring ne pose aucune restriction a ce niveau, 
comme Fillustre le code suivant : 
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<web-app> 

<servl et> 

<servl et-name>tudu</servl et-name> 
<servl et-cl ass> 

org.springf ramework.web.servlet.DispatcherServlet 
</servl et-cl ass> 

<1 oad-on-startup>K/l oad-on-startup> 
</servl et> 

<servl et-mapping><— Q 

<servl et-name>tudu</servl et-name> 

<url -pattern>*.do</url -pattern> 
</servlet-mapping> 
</web-app> 

Support des annotations pour les controleurs 

Comme indique precedemment, a partir de la version 2.5 de Spring, la configuration des 
controleurs se realise par l'intermediaire d' annotations. Bien que cette approche soit celle a 
utiliser, il reste neanmoins necessaire de l'activer dans la configuration de Spring. 

Cet aspect peut etre mis en ceuvre de deux manieres a Finstar de la configuration des compo- 
sants par l'intermediaire des annotations dans Spring. 

La premiere approche consiste a specifier une implementation de 1' interface 
HandlerMapping fondee sur les annotations. Spring MVC propose la classe Default- 
AnnotationHandlerMapping a cet effet. Cette derniere peut etre utilisee conjointement avec la 
classe AnnotationMethodHandlerAdapter arm de configurer les methodes de traitements des 
requetes dans les controleurs avec des annotations. 

Avec cette approche, les Beans des controleurs doivent etre configures en tant que Beans dans 
le contexte de Spring MVC. 

Le code suivant decrit l'utilisation de ces deux classes dans le fichier de configuration Spring 
associe a la servlet Di spatcherServl et de Spring MVC : 

<beans (...)> 

<bean class="org. spring-framework. web. servlet 

.mvc.annotation.Defaul tAnnotationHandlerMapping"/> 
<bean class="org.springframework. web. servlet 

.mvc. annotation . AnnotationMethodHandl erAdapter"/> 

</beans> 

La seconde consiste en l'utilisation de la balise component- scan de l'espace de nommage 
context arm de detecter tous les composants presents et notamment les controleurs Spring 
MVC. Ces derniers n'ont plus a etre definis en tant que Beans dans la configuration de Spring. 
Dans ce contexte, l'annotation Autowired doit etre utilisee pour l'injection de dependances. 
Pour plus de precision, reportez-vous au chapitre 2. 
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La configuration de cet aspect se realise dans le fichier de configuration Spring associe a la 
servlet DispatcherServlet de Spring MVC : 

<beans (...)> 

<context:component-scan base-package="tudu.web" /> 
j </beans> 

II est recommande de n'utiliser la premiere approche que si une personnalisation de la strate- 
gic de mappage des requetes est envisagee. La seconde approche reste done celle a utiliser par 
defaut. 

En resume 

Cette section a detaille les mecanismes generaux de fonctionnement du patron MVC de type 2 
ainsi que la structuration utilisee dans le framework Spring MVC arm de le mettre en ceuvre. 
Nous avons pu constater que les entites utilisees permettent de bien modulariser les traitements et 
d'isoler le controleur de la vue. 

Les mecanismes de chargement des contextes, de configuration du controleur facade et de 
l'approche dirigee par les annotations du framework Spring MVC ont egalement ete decrits. 

Nous allons maintenant detailler la facon dont Spring MVC gere les requetes et les vues. 

Traitement des requetes 

Comme nous 1' avons evoque precedemment, l'approche de Spring MVC afin de traiter les 
requetes est desormais completement dirigee par des annotations. Ces dernieres permettent de 
configurer aussi bien Faiguillage des requetes que les controleurs eux-memes. 

II est a noter dans ce contexte que l'annotation Controller permet de preciser qu'une classe 
correspond a un controleur MVC et qu'elle contient les traitements correspondants. 

Une fois cette annotation positionnee, le mappage des URI doit etre defini afin de selectionner 
le controleur de traitement pour une requete Web donnee. Cela se configure egalement par le 
biais des annotations, ainsi que nous le detaillons dans la prochaine section. 

Selection du controleur 

Comme pour tout framework implementant le patron MVC de type 2, un mecanisme de 
correspondance entre la classe de traitement appropriee et FURI de la requete est integre. Le 
framework configure cette correspondance en se fondant sur les informations presentes dans 
les annotations RequestMapping des controleurs. 

Afin de configurer ce mecanisme, il est indispensable de bien comprendre la structure de 
l'URL d'une requete, qui apparait toujours sous la forme suivante dans les applications Java 
EE: 

http://<machine>:<port>/<al ias-webapp>/<al i as- ressource-web> 
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L'URI correspond a la fin de FURL : 

/<al ias-webapp>/<al ias-ressource-web> 

L' alias de l'application Web, <alias-webapp>, est configure au niveau du serveur d'applica- 
tions, contrairement a celui de la ressource Web, <al ias-ressource-web>, qui se realise au sein 
de l'application. 

Dans un premier temps, Faeces a la servlet Di spatcherServl et de Spring MVC est parametre 
dans le fichier web.xml du repertoire WEB-INF afin de prendre en compte un ensemble 
d'URI avec des mappages de la forme *, /quelquechose/* ou *.quelquechose. Nous avons 
detaille la configuration de cet aspect a la section « Initialisation du controleur facade » prece- 
demment dans ce chapitre. 

Avec les annotations, F implementation DefaultAnnotationHandlerMapping de Finterface 
HandlerMapping est utilisee implicitement ou explicitement suivant la configuration. Elle se 
fonde sur les informations presentes dans les annotations de type RequestMapping. Cette 
derniere peut etre presente aussi bien au niveau de la classe du controleur que des methodes de 
ce dernier. Les informations specifiees par ce biais au niveau de la classe lui sont globales, 
avec la possibility de les surcharger au niveau des methodes. 

Cet aspect offre d'interessantes perspectives afin de configurer differents types de controleurs, 
tels que ceux a entrees multiples ou dedies a la gestion des formulaires. Nous detaillons cet 
aspect plus loin dans ce chapitre. 

Le tableau 7-1 recapitule les differentes proprietes utilisables de Fannotation RequestMapping. 



Tableau 7-1. Proprietes de I'annotation RequestMapping 



Propriete 


Type 


Description 


method 


Stri ng[] 


Specifie la ou les methodes HTTP supportees par le mappage. La specification d'une 
methode se realise par I'intermediaire des valeurs de Enumeration RequestMethod. 


params 


Stri ng[] 


Permet de realiser un mappage plus fin en se fondant sur les parametres de la requete. 
La presence ou la non-presence (avec I'operateur !) d'un parametre peut etre utilisee. 


val ue 


String[] 


Correspond a la valeur de I'annotation. Cette propriete permet de definir la ou les valeurs 
definissant le mappage de I'element. Ces valeurs peuvent eventuellement correspondre 
a des expressions regulieres au format Ant. 



Lexemple suivant illustre F utilisation de Fannotation au niveau de la classe du contro- 
leur (Q) afin de specifier la valeur du mappage ainsi qu'au niveau de la methode dediee 
au traitement de la requete (Q) : 

©Control 1 er 

@RequestMapping( "/wel come.do")<— 0 
public class Wel comeControll er { 

©RequestMappi ng<— Q 
public void welcomeO { 
(...) 

} 

} 
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Dans l'exemple ci-dessus, Fannotation ail niveau de la methode reprend les valeurs des 
proprietes de 1' annotation positionnee au niveau de la classe. 

II est egalement possible de ne specifier le mappage qu'au niveau de la methode de traite- 
ment (0) : 

©Control 1 er 

public class Wei comeControl 1 er { 

@RequestMapping(" /welcome. do" )<— O 
public void welcomeO { 
(...) 

1 

} 

Pour finir, il est egalement possible de specifier plusieurs mappages (Q) pour une meme 
annotation avec la methode HTTP d'acces souhaitee (Q) ainsi qu'un filtrage se fondant sur 
les valeurs des parametres de la requete (©), comme Fillustre le code suivant : 

©Control 1 er 

public class Wei comeControl 1 er { 

@RequestMapping( 

val ue={ "/wel come. do" , "/index. do" ) ,<— O 
tnethod=RequestMethod . GET<— Q 

params={"auth=true" , "refresh", " !authenticate"}<— Q 
public void welcomeO { 
(...) 

} 

} 

Dans l'exemple ci-dessus, la methode welcome du controleur est appelee pour les URI / 
<alias-webapp>/welcome.do ou /<alias-webapp>/index.do seulement par la methode HTTP 
GET si les conditions sur les parametres sont verifies. Dans notre cas, le parametre auth doit 
posseder la valeur true, le parametre refresh doit etre present, et le parametre authenticate 
ne doit pas l'etre. 



Les types de contrdleurs 

Comme indique precedemment, Spring MVC foumit Fannotation Controller afin de definir 
une classe en tant que controleur. Cette approche est particulierement flexible a mettre en 
ceuvre, car elle permet de s'abstraire de l'API Servlet et de definir le contenu des controleurs 
et les signatures des methodes en fonction des besoins. 

Les sections qui suivent detaillent les differents mecanismes et declinaisons utilisables afin de 
mettre en ceuvre des controleurs dans Spring MVC. 
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Controleurs de base 

Pour mettre en ceuvre les controleurs de ce type, l'utilisation de l'annotation RequestMapping 
precedemment decrite est suffisante. Les methodes sur lesquelles est appliquee cette annota- 
tion prennent en parametres des objets de type HttpServletRequest et HttpServletResponse et 
retournent un objet de type Model AndView. 

Ces controleurs peuvent etre a entrees multiples puisqu'il est possible en standard de positionner 
une annotation RequestMapping sur plusieurs de leurs methodes. 



Point d'entree 

Dans le contexte du pattern MVC, un point d'entree correspond a une methode d'un composant qui peut 
etre utilisee par le conteneur ou le framework qui le gere afin de traiter une requete. La signature de cette 
methode suit habituellement des conventions specifiques afin de pouvoir etre appelee. 



Le code suivant illustre la mise en ceuvre d'un controleur simple en se fondant sur l'annotation 
RequestMapping (Q) : 

©Control 1 er 

public class ShowTodosControl 1 er { 
(...) 

@RequestMapping( "/showTodos .do" )<— © 

public ModelAndView showTodos(HttpServletRequest request, 

HttpServletResponse response) throws Exception { 

Collection<TodoList> todoLists = new TreeSet<Todol_ist>( 
userManager .getCurrentUser( ) . getTodoLi sts( ) ) ; 

String 1 istld = nul 1 ; 

if (! todoLists . i sEmpty( ) ) ( 

listld = request .getParameter( "1 i stld" ) ; 

if (listld != null ) { 

listld = todoLi sts . iterator( ) .next( ) .getLi stld( ) ) ; 

} 

} 

Map<String, Object> model = new HashMap<String. ObjectX); 
model .put( "default Li st" , 1 i stld) ; 
return new ModelAndViewC'todos", model); 

} 

} 

Aucune autre configuration, si ce n'est l'injection des dependances avec l'annotation 
Autowi red, n'est necessaire. 

Spring MVC offre neanmoins une approche interessante et flexible afin de supporter differen- 
tes signatures de methodes de traitements des controleurs et de specifier des methodes de 
remplissage du modele. Nous decrivons cette approche, dont l'utilisation est recommandee, 
aux sections suivantes. 
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Support des parametres et retours des methodes 

En parallele de la signature type pour les methodes de traitement des controleurs, signature 
heritee des precedentes versions de Spring MVC, le framework permet si necessaire de 
s'abstraire des API Servlet et de Spring MVC. II est en ce cas possible de specifier une signa- 
ture de methodes en fonction de ses besoins. La determination des points d'entree d'un 
controleur est determinee par la presence de Fannotation RequestMapping. 

II est a noter que cette approche est egalement valable pour les methodes annotees par 
Model Attribute et InitBinder. 

Spring MVC permet de passer directement des parametres precis soit par type, soit en se 
fondant sur des annotations supplementaires. Le framework permet en outre de retourner 
differents types en fonction de ses besoins. Ces deux possibilites peuvent se combiner pour 
une plus grande flexibilite. 

Le tableau 7-2 recapitule les differents parametres supportes par Spring MVC pour les methodes 
de gestion des requetes Web, et le tableau 7-3 les types de retours possibles. 



Tableau 7-2. Types de parametres possibles pour une methode d'un controleur 



Type de parametre 


Description 


Servl etRequest ou HttpServl etRequest 


Requete par I'intermediaire de I'API Servlet. 


Servl etResponse ou HttpServl etResponse 


Reponse de la requete par I'intermediaire de I'API Servlet. 


HttpSession 


Session de I'initiateur de la requete par I'intermediaire de I'API 
Servlet. 


WebRequest ou Nati veWebRequest 


Acces d'une maniere generique aux parametres de la requete 
sans utiliser I'API Servlet. 


Local e 


Couple pays et langue associe a la requete. 


InputStream ou Reader 


Flux d'entree associe a la requete afin d'avoir acces au contenu 
de la requete. 


OutputStream ou Writer 


Flux de sortie associe a la reponse de la requete afin de generer 
le contenu de la reponse. 


Parametre annote par RequestParam 


Parametre de la requete dont I'identifiant est celui specifie dans 
I'annotation. Spring a la responsabilite de le recuperer dans la 
requete et de le convertir dans le type attendu. 


Map, Model ou Model Map 


Modele utilise pour les donnees presentees dans la vue. Celui- 
ci offre la possibilite d'avoir acces aux donnees contenues dans 
le modele et de les manipuler. 


Type correspondent a un objet de formulaire 
et annote par Model Attri bute 


Objet de formulaire recupere dans le modele en se fondant sur 
I'identifiant specifie dans I'annotation. 


Errors ou BindingResult 


Resultat du mappage et validation d'objets de formulaire. Une 
validation personnalisee peut se fonder sur ce parametre afin 
d'enregistrer les erreurs. 


SessionStatus 


Dans le cas d'un formulaire mis en ceuvre sur plusieurs pages, 
cet objet offre la possibilite de relacher les ressources mises en 
ceuvre a cet effet. 
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Tableau 7-3. Types de retours possibles pour une methode d'un controleur 



Type de retour 


Description 


Map 


Objet contenant les donnees du modele a utiliser dans la vue. L'identifiant de la vue est 
implicitement deduit par Spring MVC (voirlecas void, ou aucun objet n'est retourne). 


Model 


Identique au precedent. 


Model AndView 


Objet regroupant l'identifiant de la vue a utiliser suite aux traitements du controleur et le 
contenu du modele pour cette derniere. 


String 


Identifiant de la vue a utiliser suite aux traitements du controleur. 




Vue a utiliser suite aux traitements du controleur. 


void 


Dans le cas ou aucun objet n'est retourne, Spring MVC deduit implicitement l'identifiant 
de la vue a utiliser. Ce mecanisme se fonde sur une implementation de I'interface 
RequestToViewNameTransl ator. Limplementation par defaut extrait cet identifiant en 
enlevant les prefixe et suffixe de I'URI. Par exemple, pour un URI /showTodos.do, 
l'identifiant de la vue est showTodos. 


N'importe quel type 
annote par Model Attn - 
bute 


Objet a ajouter aux donnees du modele apres I'execution de la methode et avant celle 
de la vue. L'identifiant utilise dans I'ajout correspond a celui de I'annotation. 



Comme le montrent ces tableaux, deux annotations sont proposees pour le traitement des 
requetes, RequestParam et Model Map. Nous decrivons dans cette section l'utilisation de la 
premiere et detaillerons la seconde a la section « Controleur de gestion de formulaire ». 

L' annotation RequestParam offre la possibilite de referencer un parametre de la requete par son 
nom. L' objet correspondant est alors passe en tant que parametre. A ce niveau, une conversion 
de type est realisee si necessaire afin de coller avec le type attendu pour le parametre. 

Le code suivant illustre l'utilisation de I'annotation RequestParam afin d'avoir acces au para- 
metre de la requete d'identifiant 1 i stld par F intermediate d'un parametre d'une methode de 
traitement du controleur : 

©Control 1 er 

public class ShowTodosControl 1 er { 
(...) 

@RequestMapping( "/showTodos .do" ) 
public Model AndView showTodos ( 

©RequestParam String listld) throws Exception {<— O 

Col lection<TodoList> todoLists = new TreeSet<Todol_ist>( 
userManager .getCurrentUser( ) . getTodoLi sts( ) ) ; 

if (! todoLists . i sEmpty( ) ) { 
if (listld != null ) { 

listld = todoLi sts . iterator( ) .next( ) .getLi stld( ) ; 

} 

} 
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Map<String, Object> model = new HashMap<String, ObjectX); 
model . putt "default Li st" , 1 istld) ; 
return new Model AndView( "todos" , model); 

} 

} 

Lors de l'omission de la valeur de Fannotation RequestParam, le nom du parametre sur lequel 
elle porte est utilise. Ainsi, l'utilisation de l'annotation dans l'exemple precedent est similaire 
a la suivante (Q) : 

©Control 1 er 

public class ShowTodosControl 1 er { 
(...) 

@RequestMapping( "/showTodos.do" ) 
public Model AndView showTodos( 

@RequestParam("listId") String listld)<— O 

throws Exception { 
(...) 

} 

} 

Par defaut, l'utilisation de Fannotation RequestParam necessite la presence du parametre dans 
la requete. L'attribut requi red de Fannotation permet de parameter ce comportement afin de 
rendre le parametre optionnel, comme le montre le code suivant (0) : 

@RequestMapping( "/showTodos .do" ) 
public Model AndView showTodos ( 

©Request Pa ram( val ue="l i stld" , 

requi red="fal se" ) String listld)<— Q 
throws Exception { 
(...) 

} 

Les methodes de traitement des controleurs acceptent egalement un parametre de type 
Model Map, ce parametre correspondant aux donnees du modele. En utilisant ce parametre, il est 
possible de manipuler les donnees du modele et d'en ajouter de nouvelles. Dans ce cas, il n'est 
plus necessaire de retourner un objet de type Model AndView ; une chaine de caracteres corres- 
pondant a Fidentifiant de la vue suffit. 

Le code suivant illustre Fadaptation de l'exemple precedent (Q) afin d'utiliser ce 
mecanisme : 
©Control 1 er 

public class ShowTodosControl 1 er { 
(...) 

@RequestMapping( "/showTodos.do" ) 
public String showTodos ( 

©RequestParam String 1 istld, 

ModelMap model) throws Exception {<— Q 

Collection<TodoList> todoLists = new TreeSet<Todol_ist>( 
userManager . getCur rent User ( ) .getTodoLi sts( ) ) ; 
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if ( ! todoLists . i sEmpty ( ) ) { 
if (Ustld != null ) { 

listld = todoLi sts . i terator( ) .next( ) .getLi stld( ) ; 

} 

} 



model . addAttri bute( "def aul t Li st" , listld) ;<— O 
return "todos" ;<— Q 

} 

} 

Les principaux autres types de parametres et de retour sont decrits dans les sections suivantes. 
Controleur de gestion de formulaire 

Spring MVC fournit un support pour l'affichage des donnees des formulaires et leur soumis- 
sion a Faide d' annotations. Ce support se fonde sur les differents concepts et annotations 
decrits aux sections precedentes. 

Bien que ce type de controleur utilise un Bean afin de stacker les informations des formulai- 
res, aucune configuration n'est a realiser pour Finjection de dependances. II suffit que ce Bean 
soit present dans les donnees du modele et que Fidentifiant correspondant soit specifie dans le 
formulaire. 

La section suivante se penche sur la facon d'implementer la gestion des formulaires HTML au 
moyen de Fapproche orientee annotations de Spring MVC. 

Affichage du formulaire 

Lutilisation des annotations RequestMapping, Model Attribute et InitBinding permet de char- 
ger les differentes entites necessaires a l'affichage du formulaire dans la vue. Les methodes 
sur lesquelles sont appliquees ces annotations, prennent alors part au cycle de traitement de la 
requete et adressent des problematiques distinctes et s'enchainent dans un ordre bien precis. 

L affichage du formulaire est realise grace a Fappel d'une methode de traitement de la requete 
par le biais de la methode GET. Le cycle d'enchainement des methodes est illustre a la 
figure 7-4. 

Spring MVC permet d'initialiser Fobjet de formulaire en se fondant sur une methode annotee 
par Model Attri bute. Cet objet doit etre retourne par la methode et est automatiquement ajoute 
dans le modele. II peut done etre utilise par la suite dans la vue pour initialiser le formulaire 
correspondant. 

Le comportement habituel consiste a creer une instance vierge a chaque demande d' affichage 
du formulaire si aucun parametre n'est specifie. Si un parametre est present dans la requete, 
celui-ci peut etre alors utilise, par exemple, afin de recuperer une instance initialisee avec des 
valeurs de la base de donnees. 
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Figure 7-4 

Enchatnement des methodes 
permettant I 'affichage des 
donnees d'unformulaire 



Requete GET 



Methodes annotees par 
ModelAttribute 





Methode annotee par InitBinder 



Methode annotee par 
RequestMapping avec 
method=RequestMethod.GET 



^ 

Methode annotee par InitBinder 



Vue 

Le code suivant, tire de Tudu Lists, donne un exemple d' utilisation de la methode 
initFormObject (Q) de ce type : 

(...) 

public class Mylnf oControl 1 er { 
(...) 

©Model Attribute ("user info" ) 

public Userlnf oData initFormObject(<— Q 

HttpServl etRequest request) { 

String login = request. getRemotellser( ) ; 

User user = userManager.findUser(login) ; 

UserlnfoData data = new UserInfoData( ) ; 

data . set Password (user .get Pas sword ( ) ) ; 

data . setVerifyPassword(user .get Pas sword ( ) ) ; 

data . setFi rstName( user .get Fi rstNamet ) ) ; 

data . set La st Name (user .get Last Name ( ) ) ; 

data . setEmai 1 (user .getEmai 1 ( ) ) ; 

return data; 

} 

(...) 

} 

Les Property Editor personnalises sont ajoutes par l'intermediaire d'une methode annotee par 
Ini tBi nder afin de convertir les proprietes du Bean de formulaire en chaines de caracteres affi- 
chables dans des champs. Cette methode doit posseder un parametre de type WebDataBinder 
afin de pouvoir les enregistrer. 
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Le code suivant indique la facon d'ajouter un Property Edi tor dans un controleur de gestion de 
formulaire en se fondant sur Fannotation InitBinder (Q) : 

(...) 

public class MylnfoControl 1 er { 
(...) 

©InitBinder 

public void initBinder(WebDataBinder binder) {<— O 
binder. regis terCustomEdi tor (MyCl ass . cl ass , 

new MyPropertyEditor( ) ) ; 

} 

(...) 

} 

Cette methode est utilisee afin d'afficher les valeurs du Bean de formulaire dans la vue corres- 
pondante sous forme de chaines de caracteres. 

II est possible d'ajouter des elements dans le modele par 1' intermediate de l'annotation 
Model Attribute. Ces elements peuvent etre utilises dans la construction du formulaire afin 
notamment d' initialiser des listes de selection, des boutons radio ou des cases a cocher. Autant 
de methodes que d'elements a ajouter doivent etre definies. 

Le code suivant montre la facon d'ajouter les donnees necessaries afin d'initialiser un formu- 
laire en se fondant sur l'annotation Model Attri bute (Q) : 

(...) 

public class MylnfoControl 1 er { 
(...) 

@Model Attri bute( "datas" ) 

public List<String> popul ateDataLi st( ) {<— O 

List<String> datas = new Arrayl_ist<String>( ) ; 
datas . add( "my data" ) ; 
return datas; 

} 

(...) 

} 

Pour finir, il convient de definir une methode de traitement dediee a l'amchage du formulaire. 
Cette derniere doit etre annotee avec RequestMapping et posseder la propriete method avec la 
valeur RequestMethod.GET. Le mappage avec l'URI peut etre specifie a ce niveau ou globale- 
ment au niveau de la classe. Cette methode ne possede pas particulierement de traitements, 
mais specifie la vue correspondant au formulaire. 

Le code suivant illustre un exemple de methode de ce type annote par RequestMapping (Q) : 
(...) 

public class MylnfoControl 1 er { 
(...) 

@RequestMapping(method = RequestMethod.GET) 
public String showFormO {<— O 
return "userinfo"; 

} 

(...) 

} 
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Soumission du formulaire 

L'utilisation des annotations RequestMapping, Model Attribute et InitBinding permet de definir 
des methodes de remplissage de l'objet de formulaire avec les donnees soumises et de les trai- 
ter. Ces methodes adressent des problematiques distinctes et s'enchainent dans un ordre 
precis. 

La soumission du formulaire est traitee grace a l'appel d'une methode de traitement de la 
requete par la methode POST. Le cycle d'enchainement des methodes est illustre a la figure 7-5. 

Figure 7-5 

Enchatnement des methodes 
permettant la soumission 
des donnees d'un 
formulaire 



Methode annot< 


3e par InitBinder 




/ 


Methode annotee par 
RequestMapping avec 
method= RequestMethod. POST 




/ 


Methode annotee par InitBinder 



I 

Vue 

Les premieres methodes annotees avec RequestMapping et InitBinder (respectivement 
initFormObject, initBinder) fonctionnent de la mime maniere que precedemment 

Une validation des donnees d'un formulaire peut etre mise en ceuvre si necessaire. La valida- 
tion liee au mappage des donnees du formulaire dans l'objet correspondant est directement 
integree dans le cycle de traitements. Par contre, avec l'approche fondee sur les annotations, 
Spring MVC n'integre pas les validations personnalisees dans ce cycle. Neanmoins, il est 
recommande d'utiliser l'interface Validator afin de regrouper ces traitements. Le code de 
cette interface est le suivant : 

public interface Validator { 

boolean supports(Class clazz); 

void val idate(Object obj , Errors errors); 

} 

La methode supports permet de specifier sur quel Bean de formulaire peut etre appliquee 
l'entite de validation. La methode val i date doit contenir F implementation de la validation et 
utiliser l'instance de l'interface Errors associee. 



Requete POST 

1 

Methodes annotees par 
ModelAttribute 
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Le ou les validateurs sont associes ail controleur soit par injection de dependances, soit par 
une instanciation directe, cette derniere etant peu coflteuse. 

Le code suivant de la classe Register-Validator montre que 1' implementation du validateur 
permet de specifier des erreurs aussi bien a un niveau global (Q) que sur chaque propriete du 
formulaire (Qi) en s'appuyant sur l'interface Errors : 

public class RegisterValidator implements Validator { 

public boolean supports(Cl ass clazz) { 

return Regi sterData . cl ass . i sAssi gnabl eFrom(cl azz) ; 

} 

public void val idate(Object command, Errors errors) { 

Val i dati onLIti 1 s . rej ect If Empty OrWhitespace( errors , "login" , 

"errors . requi red" , new Object[] {"login"}, "");<— Q 
Val idationUti 1 s . rej ect If Empty Orwhitespace( errors , "password" , 

"errors . requi red" , new Object[] {"password"}, "");<— Q 

Val idationUti 1 s . rej ect If Empty Orwhi tespace( 
errors, "verifyPassword" , 

"errors . requi red" , new Object[] {"verifyPassword"}, "");<— Q 
if( !data .getPassword( ) .equal s(data .getVerifyPassword( ) ) ) { 
errors . rejectVal ue( "verifyPassword" , "errors . requi red" , 
new Object[] {"verifyPassword"}, "");<—© 

} 

Val idationUti 1 s . rej ect If Empty Orwhitespace( errors , "f i rstName" , 
"errors . requi red" , new Object[] {"fi rstName" } , "");<— Q 
Val i dati onUti 1 s . rej ect If EmptyOrWhi tespace( 
errors, "lastName", 

"errors . requi red" , new Object[] {"lastName"}, "");<— Q 

if( errors. hasErrors( ) ) { 
errors . rej ect ( "regi ster . info. 1" ) ;<— O 

} 

} 

} 

La methode de traitement dediee a la soumission du formulaire doit etre annotee avec 
RequestMapping et posseder la propriete method avec la valeur RequestMethod. POST. Cette 
derniere prend en parametre Fobjet de formulaire, objet annote par Model Attribute et a la 
responsabilite de traiter cet objet. 

Le code suivant illustre la mise en ceuvre d'une methode de ce type dans le cadre du controleur 
MylnfoController, methode nominee submitForm (Q) : 

(...) 

public class MylnfoController { 
(...) 



@RequestMapping(method = RequestMethod . POST) 
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public String submitForm(<— Q 

@ModelAttribute("userinfo") UserlnfoData userlnfo, 
BindingResult result) { 

User user = userManager.findUser(userInfo.getl_ogin( ) ) ; 
user . set Password (user Info . getPassword( ) ) ; 
user . set Fi rs t Name (user Info. get Fi rstName( ) ) ; 
user . set Last Name (user Info. get Last Name ( ) ) ; 
user . set Emai 1 ( user Info. get Email ( ) ) ; 
userManager.updateUser(user) ; 

return "userinfo"; 



Si une validation est mise en ceuvre, cette methode a en charge la specification de la vue d'affi- 
chage du formulaire en cas d'echec de validation. A cet effet, elle doit prendre un parametre 
de type BindingResult correspondant au resultat du mappage. Ce parametre pourra etre passe 
a la methode val i date du validate ur. 

Le code suivant illustre F integration d'un validateur (©) dans les traitements de soumission 
du controleur : 

(...) 

public class Mylnf oControl 1 er { 



@RequestMapping(method = RequestMethod. POST) 
public String submitForm( 

@ModelAttribute("userinfo") UserlnfoData userlnfo, 

BindingResult result) { 

(new Regi sterVal idator( ) ) . val idate(userInfo, result);<— Q 
if ( ! resul t . hasErrors( ) ) {<— O 

User user = userManager .f indUsertuserlnfo . getLogin( ) ) ; 

user . set Pas sword (user Info .get Password ( ) ) ; 

user . set Fi r s tName (user Info. get Fi rstName( ) ) ; 

user . set Last Name (user Info .get Las tName( ) ) ; 

user . set Emai 1 (user Info. get Email ( ) ) ; 

userManager.updateUser(user) ; 



(...) 



) 



return "userinfo"; 



(...) 



Lors de 1' utilisation d'une vue fondee sur JSP/JSTL, les balises du taglib form de Spring 
offrent un support a Faffichage des donnees du formulaire ou des erreurs de validation. Son 
utilisation est detaillee plus loin dans ce chapitre. 
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Support des formulaires sur plusieurs pages 

Spring MVC supporte la mise en oeuvre d'un formulaire sur plusieurs pages, la session Web devant dans 
ce cas etre utilisee. Le framework offre la possibilite de gerer implicitement le stockage de I'objet de formu- 
laire a ce niveau. 

Pour ce faire, il convient de preciser que I'objet de formulaire est stocke en session par I'intermediaire de 
I'annotation SessionAttributes au niveau de la classedu controleur. Cette annotation permet de speci- 
fier I'identifiant correspondant. 

Pour liberer les ressources associees lors d'un succes de la soumission du formulaire sur la derniere page, il 
convient d'utiliser la methode setComplete sur un objet de type SessionStatus. Un parametre de ce type 
peut etre passe directement en tant que parametre de methodes de traitement de requetes dans les controleurs. 
Le code suivant est un exemple simple d'utilisation de cette approche, a savoir la configuration de I'objet 
de formulaire pour un stockage en session (A), le passage d'un parametre de type SessionStatus (Q) 
et I'utilisation de la methode setCompl ete (Q) sur cet objet : 

(...) 

@SessionAttributes( "userinfo" )<— A 
public class MylnfoController { 
(...) 

@RequestMapping(method = RequestMethod. POST) 
public String submitForm( 

@ModelAttribute("userinfo") UserlnfoData userinfo, 
BindingResult result, 
SessionStatus status) {<— Q 
(new Regi sterVal idatort ) ) . val idate(userInfo, result); 
if (! result . hasErrors( ) ) { 

status. setCompl ete ( ) ;<— Q 
(...) 

} 

(...) 

} 

) 



Gestion des exceptions 

Par defaut, Spring MVC fait remonter les differentes exceptions levees dans le conteneur de 
servlets. II est cependant possible de modifier ce comportement par I'intermediaire de l'inter- 
face Handl er Except i on Resol ver, localisee dans le package org. springf ramework.web. servl et : 

public interface HandlerExceptionResolver { 

ModelAndView resolveException(HttpServletRequest request, 

HttpServl etResponse response, Object handler, Exception ex); 

} 

Le developpeur peut choisir d'utiliser ses propres implementations ou la classe 
Simpl eMappi ngExcepti onResol ver du package org . spri ngf ramework . web . servl et .handl er fournie 
par le framework. Cette derniere permet de configurer les exceptions a traiter ainsi que les 
vues qui leur sont associees. L' exception est alors stockee dans la requete avec la cle excepti on, 
ce qui la rend disponible pour un eventuel affichage. 
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Cette implementation se parametre de la maniere suivante : 

<bean i d=" except i on Resol ver" cl ass="org. springf ramework.web 

. servl et . handl er . Simpl eMappi ng Except ion Resol ver"> 
<property name=" except ionMappings"> 
<props> 

<prop key=" org. springf ramework.dao. Data Access Except ion "> 

dataAccessFai 1 ure 
</prop> 

<prop key="org. springf ramework. transaction 

.Transact ion Except i on "> 

dataAccessFai 1 ure 
</prop> 
</props> 
</property> 
</bean> 



En resume 

Spring MVC met en ceuvre une approche interessante pour les controleurs MVC fondee sur 
les annotations. Elle offre ainsi la possibilite de s'abstraire de l'API Servlet en laissant le 
framework realiser cette manipulation. Les signatures des points d' entree des controleurs 
peuvent etre adaptees en fonction des besoins et de F approche souhaitee. 

Au-dela du cadre general propose par le framework, plusieurs declinaisons sont possibles, 
comme 1' utilisation de controleurs simples ou de formulaire pour la recuperation des parame- 
tres de la requete, le remplissage du modele et la selection de la vue. 



Spring MVC et la gestion de la vue 

Cette section se penche sur la facon dont sont traitees les vues au sein du framework Spring 
MVC. 

Selection de la vue et remplissage du modele 

Spring MVC abstrait completement la vue du controleur, masquant ainsi sa technologie et sa 
mise en ceuvre. Au niveau du controleur, le developpeur a la responsabilite de remplir le 
modele avec les instances utilisees dans la vue et de specifier son identifiant. 

Differentes approches sont possibles pour cela, qui visent toutes a faciliter l'utilisation de 
Spring et la mise en ceuvre des controleurs. 

La premiere se fonde sur la classe Model AndView dans le package 
org. springf ramework. web. servlet. Les donnees vehiculees par cette classe sont utilisees afin 
de selectionner la vue, la classe lui fournissant les donnees du modele. De ce fait, le deve- 
loppeur ne manipule plus l'API Servlet pour remplir le modele et passer la main aux traite- 
ments de la vue. 
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Cette classe doit etre utilisee en tant que retour d'une methode de traitement de requetes anno- 
tee avec RequestMapping. Une instance de la classe Model AndView doit alors etre instanciee et 
remplie a ce niveau. 

Les donnees du modele sont stockees sous forme de table de hachage. Le code suivant donne 
un exemple de mise en ceuvre de ce mecanisme (Q), dans lequel Fidentifiant todos corres- 
pond a un nom symbolique de vue configure dans Spring MVC : 

@RequestMapping( "/showTodos .do" ) 

public ModelAndView showTodos(HttpServl etRequest request, <— © 
HttpServl etResponse response) throws Exception { 

String 1 i st Id = (...); 

Map<String,Object> model = new HashMap<String,Object>( ) ; 

model . put( "def aul tList" , 1 i stld) ; 

return new Model AndView( "todos" , model );<—© 

} 

La seconde approche consiste en l'utilisation de la classe Map ou Model ou Model Map en tant que 
parametre d'une methode de traitement annotee avec RequestMappi ng. Dans ce cas, ce parame- 
tre correspond a l'entite de stockage des elements du modele. Lidentifiant de la vue et ces 
donnees sont desormais dissociees. 

Si aucun identifiant de vue n'est precise, Spring MVC le deduit de l'URI. Par exemple, si la 
vue se finit par /showTodos. do, l'identifiant deduit est showTodos. II est neanmoins possible de 
specifier explicitement l'identifiant de la vue choisie en le faisant retourner sous forme de 
chaine de caracteres par la methode. 

Le code suivant illustre l'utilisation de la classe Model Map pour gerer les donnees du modele, 
ainsi que la maniere de specifier implicitement (Q) et explicitement (Q) l'identifiant de la vue : 

©RequestMappi ng( "/wel come. do") 

public void wel come(Model Map model) throws Exception {<— © 
(...) 

//L'identifiant de la vue est deduit 
//et correspond a welcome 

} 

©RequestMappi ng( "/showTodos .do" ) 

public String showTodos(ModelMap model) throws Exception {<— Q 
String listld = (...); 

model . addAttribute( "def aul tList" , listld); 
//L'identifiant de la vue est retourne 
return "todos"; 

} 

En parallele des methodes de traitement des requetes, il est possible d'ajouter d'autres 
elements dans le modele en utilisant le retour des methodes annotees par Model Attribute. 
Dans ce cas, le retour est automatiquement ajoute au modele, avant meme que la methode de 
traitement de la requete soit appelee. 
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Le code suivant illustre l'utilisation de Fannotation ModelAttribute (Q) afin d'ajouter le 
retour d'une methode dans le modele et la verification de la presence de cet objet (Q) dans la 
methode de traitement d'une requete : 

@Model Attri bute( "user" )<— Q 
public User getCurrentUser( ) { 

return userManager.getCurrentllser( ) ; 

} 



@RequestMapping("/showTodos .do" ) 

public String showTodos(ModelMap model) throws Exception { 
User user = (User)model . get( "user" ) ;<— Q 
(...) 

return "todos"; 

} 



Configuration de la vue 

La selection des vues dans Spring MVC est effectuee par le biais d'une implementation de 
l'interface ViewResolver dans le package org.springframework.web.servlet, comme le 
montre le code suivant : 

public interface ViewResolver { 

View resolveViewName(String viewName, Locale locale); 

} 

Les sections qui suivent detaillent les differentes implementations de cette interface. La 
figure 7-6 illustre la hierarchie de ces classes et interfaces. 

Figure 7-6 

Hierarchie des 
implementations de 
l'interface ViewResolver 

AbstractCachingViewResolver 

2 



ViewResolver 

m 



UrIBasedViewResolver 



ResourceBundle ViewResolver 



Xml ViewResolver 



InternalResource ViewResolver 



AbstractTemplateViewResolver 
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ResourceBundleViewResolver 

La premiere implementation, ResourceBundleViewResolver, correspond a une configuration 
au cas par cas des vues utilisees. Cette approche est particulierement interessante pour une 
utilisation des vues fondees sur differentes technologies de presentation. Sa configuration 
s'effectue par le biais d'un fichier de proprietes contenant le parametrage des differentes 
vues. 

Cette classe peut toutefois devenir vite contraignante si la majeure partie des vues utilise 
la meme technologie de presentation. Les applications qui utilisent JSP/JSTL et des vues 
PDF ou Excel pour afficher des etats sont un exemple de cette contrainte. Spring MVC 
offre une solution fondee sur le chainage de ViewResolver pour optimiser la resolution de 
ce probleme. 

Le code suivant montre de quelle maniere configurer cette implementation avec Spring MVC : 

<bean id="viewResolver" class-"org.springframework 

.web. servl et . view. ResourceBundl eViewResol ver"> 
<property name="basename" val ue="views"/> 
</bean> 

La propriete basename permet de specifier le fichier de proprietes utilise, qui, dans l'exemple 
suivant, apournom views. properties : 

register_ok.class=org. springframework. web. servl et. view. Red irectView 
regi ster_ok. url=wel come. action 

recover_password_ok.cl ass 

=org.springf ramework. web. servl et. view. Redi rectView 
recover_password_ok. url=wel come . acti on 

todo_l ists_report.class=tudu. web. ShowTodoListsPdf View 

rssFeed . cl ass-tudu .web . RssFeedVi ew 

rssFeed. styl esheetl_ocation=/WEB- INF/xsl /rss .xsl 

Ce fichier possede les configurations des vues de redirection ainsi que des vues fondees sur la 
technologie XSLT et le framework iText. 

XmlViewResolver 

Les vues sont definies par l'intermediaire de cette implementation au cas par cas, comme 
precedemment, mais dans un sous-contexte de Spring. L utilisation de toutes les fonctionnalites et 
mecanismes du framework est done envisageable, de meme que Finjection de dependances 
sur la classe d' implementation des vues. 

La configuration de cette implementation se realise de la maniere suivante en utilisant par 
defaut le fichier /WEB-INF/views.xml, tout en n'ecartant pas la possibilite d'en specifier un 
autre par le biais de la propriete location : 



<bean id="viewResolver" 
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cl ass-" org. springf ramework.web 
<property name="order" value-"2" 
<property name="localtion" value 
</bean> 

Internal Resource ViewResolver 

L' implementation Internal ResourceViewResol ver utilise les URI dans le but de resoudre les 
vues fondees, par exemple, sur les technologies JSP/JSTL. Ce mecanisme construit l'URI a 
partir de Fidentifiant de la vue puis dirige les traitements vers d'autres ressources gerees par 
le conteneur de servlets, telles que des servlets ou des JSP, comme dans 1' exemple ci-dessous : 

<bean id-"jspViewResolver" class="org.springframework.web 

. servl et . view. Internal ResourceViewResol ver" > 
<property name="viewClass" 

va 1 ue=" o rg. springf ramework.web. servl et. view. J stlView"/> 
<property name="prefix" val ue="/WEB-INF/jsp/"/> 
<property name="suff ix" val ue=" . jsp"/> 
</bean> 

Cette implementation generale s' applique a toutes les vues, excepte celles qui sont resolues 
precedemment par une autre implementation dans une chaine de Vi ewResol ver. 

Chainage d'implementations de ViewResolver 

Spring MVC offre la possibilite de chainer les entites de resolution des vues. Le framework 
parcourt dans ce cas la chaine jusqu' a la decouverte du ViewResolver approprie. 

Certaines de ces entites s'appliquant a toutes les vues, une strategie par defaut de resolution 
des vues peut etre definie. Les implementations fondees sur Url BasedViewResol ver, telles que 
Internal ResourceViewResol ver, fonctionnent sur ce principe. 

Lutilisation des vues fondees sur JSP/JSTL peut etre specifiee. D'autres vues, comme des redi- 
rections ou des vues generant des flux PDF ou Excel, sont definies ponctuellement dans un fichier. 

La figure 7-7 illustre un chainage d'implementations de l'interface de ViewResolver tire de 
Tudu Lists. 

Sans cette fonctionnalite, la configuration de toutes les vues au cas par cas dans un fichier 
serait necessaire, meme pour celles ne necessitant pas de parametrage specifique. 

L'exemple suivant decrit la configuration du chainage de Vi ewResol ver : 

<bean id="jspViewResolver" class="org.springframework.web 

. servl et. view. Internal ResourceViewResol ver"> 
<property name="viewClass" 

va 1 ue=" o rg. springf ramework.web. servl et. view. J stlView"/> 
<property name="pref ix" val ue="/WEB-INF/jsp/"/> 
<property name="suff ix" val ue=" . jsp"/> 
</bean> 



. servl et .vi ew.Xml Vi ewResol ver"> 
/> 

="/WEB-INF/views.xml" /> 
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<bean id="viewResolver" 

cl ass-" org. spri ngf ramework. web. servlet. view. Xml ViewResol ver"> 
<property name="order" value="l"/> 

<property name="location" val ue="/WEB- INF/views .xml "/> 
</bean> 

La propriete order permet de specifier la position du ViewResol ver dans la chaine. Cet exemple 
met en evidence que la classe Internal ResourceViewResol ver ne possede pas cette propriete, 
ce ViewResol ver ne pouvant etre utilise qu'en fin de chaine. 



Figure 7-7 
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Traitements de la vue en utilisant les 
technologies JSP/JSTL 



Les technologies de presentation 

Spring MVC propose plusieurs fonctionnalites qui simplifient enormement la mise en ceuvre 
des technologies et frameworks de presentation. 

Dans Spring MVC, une vue correspond a une implementation de 1' interface View du package 
org. springframework. web. servlet telle que decrite dans le code suivant : 

public interface View { 

void render(Map model, HttpServl etRequest request, 

HttpServl etResponse response); 

} 

Cette interface possede plusieurs implementations, localisees dans le package 
org. springframework. web. servlet. view ou dans un de ses sous-packages. 

La figure 7-8 illustre la hierarchie de ses classes et interfaces. 



Figure 7-8 
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JstlView 




TilesView 
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AbstractJExcelView 



AbstractPdfView 
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Vue de redirection 

Spring MVC definit un type de vue particulier afin de rediriger les traitements vers un URI ou 
une URL par F intermediate de la classe RedirectView. Elle se configure avec l'implementa- 
tion ResourceBundleViewResol ver ou Xml ViewResol ver en imposant de definir la propriete url . 

Le code suivant donne un exemple de sa mise en ceuvre dans Tudu Lists : 

register_ok.class-org.springframework.web.servlet.view.Redi rectView 
regi ster_ok.url=wel come. action 

La propriete url permet de specifier l'adresse de redirection correspondante, laquelle est, dans 
notre cas, relative au contexte de 1' application. 

La figure 7-9 illustre l'enchamement des traitements afin d'utiliser une vue de type 
Redi rectView. 



Figure 7-9 
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Cette vue peut etre configuree plus rapidement et directement dans la configuration des 
controleurs grace au prefixe redi rect (0), comme l'illustre le code suivant : 

public class RestoreTodoListController { 
(...) 

@RequestMapping(method = RequestMethod . POST) 
public String submitForm( 

©Model Attribute( "restoredata" ) RestoreData restoreData, 

BindingResult result, 

SessionStatus status) { 
(...) 

return "redi rect : showTodos . action" ;<— O 

} 

} 

Vue fondee sur JSP/JSTL 

Spring MVC fournit une vue fondee sur JSP/JSTL, dirigeant les traitements de la requete vers 
une page JSP dont l'URI est constrait a partir de l'identifiant de la vue. 

La figure 7-10 illustre l'enchainement des traitements afin d'utiliser une vue de type Jstl Vi ew. 



IntemalResourceView 



DispatchServlet 



Appelle la methode renderpour la 
vue determinee par un ViewResolver. 



JstlView 



Methode render 



Appelle la methode forward sur une 
instance de RequestDispatcher. 



Figure 7-10 

Enchainement des traitements pour la vue 



Le developpeur prend uniquement en charge le developpement de la page JSP, tandis que 
Spring MVC a la responsabilite de mettre a disposition dans la requete tout le contenu du 
modele ainsi qu'eventuellement des informations concernant le formulaire. 

Les balises et expressions JSTL peuvent etre utilisees d'une maniere classique en utilisant les 
donnees du modele, ces dernieres etant mises a disposition par Spring MVC pour les pages 
JSP. Pour une entree ayant pour cle maVari abl e dans le modele, la page JSP recupere la valeur 
de sa propriete maPropriete correspondante de la maniere suivante : 
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<c:out val ue="$ {maVari abl e .maPropri ete} "/> 

Afin d'utiliser les taglibs JSTL, des importations doivent etre placees dans les pages JSP, 
comme dans le code suivant, tire de la page WEB-INF/jspf/header.jsp : 

< %@ t a g 1 i b prefix="c" uri="http://java. sun.com/jstl/core_rt" %> 
| <%@ tagl i b pref ix="fmt" uri="http://java. sun.com/jstl/fmt_rt" %> 

Ainsi, l'africhage de la liste des todos dans une page JSP se realise de la maniere suivante 
(cette liste ayant ete specifiee dans le modele) : 

Affichage de la liste des todos: 
<c:forEach items="$ {todos} " var="todo"> 

- <c:out value="${todo.id}"/>, <c:out val ue-"$ {todo . name} "/><br/> 
</c:forEach> 

Au niveau des formulaires, un taglib dedie permet de realiser le mappage entre les donnees du 
formulaire et les champs correspondants. Pour pouvoir Futiliser, F importation suivante (tiree 
de la page WEB-INF/jspf/header.jsp) doit etre placee dans les pages JSP : 

<%@ taglib pref ix="form" 

uri="http: //www. springframework.org/tags/form" %> 

Le tableau 7-4 recapitule les balises proposees par ce taglib pour construire des formulaires. 



Tableau 7-4. Balises du taglib form de gestion de formulaires 



Balise 


Description 


checkbox 


Definit un element de formulaire de type case a cocher pour un attribut du Bean de formulaire. 


checkboxes 


Definit un ensemble d'elements de formulaire de type case a cocher pour un attribut de formu- 
laire. L'initialisation des valeurs des elements se realise a partir d'une liste presente dans le 
modele. 


errors 


Affiche les erreurs survenues lors de la soumission d'un formulaire a un niveau global ou par 
champ. 


form 


Definit un formulaire et le rattache eventuellement a un Bean de formulaire. 


hidden 


Definit un element de formulaire cache pour un attribut du Bean de formulaire. 


input 


Definit un element de formulaire de type texte pour un attribut du Bean de formulaire. 


option 


Definit un element de liste. 


options 


Definit un ensemble d'elements de liste. Linitialisation des valeurs des elements se realise a par- 
tir d'une liste presente dans le modele. 


password 


Definit un element de formulaire de type mot de passe pour un attribut du Bean de formulaire. 


radiobutton 


Definit un element de formulaire de type bouton radio pour un attribut du Bean de formulaire. 


radiobuttons 


Definit un ensemble d'elements de formulaire de type bouton radio pour un attribut du Bean de formu- 
laire. Linitialisation des valeurs des elements se realise a partir d'une liste presente dans le modele. 


sel ect 


Definit un element de formulaire de type liste pour un attribut du Bean de formulaire. Cette balise 
doit etre utilisee conjointement avec les balises option et options afin de specifier les valeurs 
de la liste. 


textarea 


Definit un element de formulaire de type zone de texte pour un attribut du Bean de formulaire. 

1 
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Ces balises permettent de referencer les attributs d'un Bean de formulaire mis a disposition 
dans le modele a l'aide des techniques decrites precedemment a la section « Controleur de 
gestion de formulaire ». 

La correspondance entre le formulaire et le Bean de formulaire se realise au niveau de la 
balise form par F intermediate du champ modelAttribute, qui specifie le nom de F entree dans 
le modele. 

L' utilisation des balises du taglib form permet d' initialiser automatiquement les champs du 
formulaire avec les donnees du formulaire et d'afficher les eventuelles erreurs survenues. Le 
code suivant montre F utilisation de cette balise dans la page JSP WEB-INF/jsp/user_info.jsp 
de F etude de cas : 

<form:form model Attribute-" userinfo"><— Q 
<tr cl ass-"odd"> 
<td> 

<fmt: mess age key="user .info.fi rst.name"/> 
</td> 
<td> 

<form:input path="f i rstName" size-"15" maxl ength="60"/><— Q 
 <font color="red"> 
<form:errors path="f i rstName"/X/font><— Q 
</td> 
</tr> 
(...) 
</form:form> 

La balise form permet de definir Fidentifiant de F element dans le modele correspondant au 
Bean de formulaire en se fondant sur Fattribut model Attn' bute (©). Elle permet egalement de 
delimiter les elements du formulaire. 

Au sein du formulaire, les champs correspondant aux attributs du Bean de formulaire peuvent 
etre specifies. La correspondance entre le champ et Fattribut correspondant se realise par 
Fintermediaire de Fattribut path de la balise. Dans notre exemple, la balise input (Q) porte 
sur la propriete f i rstName du Bean de formulaire ayant pour nom userinfo. 

Laffichage des erreurs, generates ou associees a un champ, se realise par Fintermediaire de la 
balise errors. Lattribut path permet de preciser les erreurs a afficher. Avec une valeur *, 
toutes les erreurs relatives au formulaire sont affichees. Avec le nom d'un champ, comme dans 
F exemple precedent (0), Feventuelle erreur correspondant au champ est affichee. 

Autres vues 

Spring MVC apporte des supports pour toutes sortes de vues qui ne sont pas necessairement 
fondees sur des redirections internes au conteneur de servlets (methode forward) ou des redi- 
rections de requetes (methode sendRedi rect), notamment des classes abstraites de base pour 
les technologies suivantes : 

• generation de documents (PDF, Excel, etc.) ; 

• generation de rapports avec Jasper Reports ; 
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• generation de presentations fondees sur des templates (Velocity, FreeMarker) ; 

• generation de presentations fondees sur les technologies XML. 

Concernant les vues generant des documents et celles fondees sur les technologies XML, le 
framework Spring MVC instancie les ressources representant le document par le biais de 
methodes generiques. II delegue ensuite les traitements a une methode de la vue afin de construire 
le document ou de convertir le modele dans une technologie donnee. Le framework reprend 
ensuite en main ces traitements afin d'executer eventuellement une transformation puis 
d'ecrire le resultat sur le flux de sortie. 

La figure 7-11 illustre Fenchamement des traitements d'une vue generant un document avec 
le support PDF de Spring MVC. 



Abstract PdfView 



MyView 



Creation du document PDF, 
initialisation du document en 
utilisant les API iText 



Appel de la methode 
buildPdf Document 



Construction du document 
PDF 



Positionnement des en-tetes 
HTTP 



Ecriture du document sur le 
flux de sortie 



Figure 7-11 

Enchainement des traitements de la vue 



Dans l'exemple decrit a la figure 7-11, la classe MyView etend la classe abstraite 
AbstractPdfView du package org. springf ramework. web. servlet. view afin d'implementer la 
methode abstraite buildPdf Document. C'est pourquoi la classe MyView ne contient plus que les 
traitements specifiques a 1' application pour la construction du document, son instanciation et 
son renvoi au client etant encapsules dans la classe AbstractPdfView. 
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En resume 

Approfondissant les principes de gestion de la presentation au sein du framework Spring 
MVC, nous avons vu que ce dernier met en ceuvre des mecanismes de mise en relation d'un 
identifiant et de sa vue, tout en favorisant la coexistence de vues fondees sur diverses tech- 
nologies. Le framework permet l'utilisation d'un nombre important de technologies de 
presentation. 

La mise a disposition des donnees presentes dans le modele pour les vues est realisee automa- 
tiquement par le framework. 

Support de REST (Representational State Transfer) 

La version 3.0 de Spring introduit le support natif de la technologie REST afin d'utiliser les 
URI conformes a ce format tout en suivant le modele de programmation de Spring MVC 
fonde sur les annotations. 



La technologie REST 

Cette technologie correspond a une maniere de construire des applications pour les systemes distribues. 
REST n'est pas un protocole ou un format, mais correspond au style architectural original du Web, bati sur 
les principes simples suivants : 

— LURI est tres important puisque, dans ce contexte, connaitre ce dernier doit suffire pour acceder a la 
ressource. II n'est plus besoin de specifier des parametres supplementaires. De plus, la manipulation de la 
ressource se fonde sur l'utilisation des operations du protocole HTTP (GET, POST, PUT et DELETE, 
essentiellement). 

— Chaque operation est autosuffisante, et aucun etat n'est stocke au niveau de la ressource. Le client a la 
responsabilite du stockage de cet etat. En parallele, la technologie utilise des standards hypermedias tels 
que HTML ou XML afin de realiser les liens vers d'autres ressources et d'assurer ainsi la navigation dans 
I'application. 

— II est possible de mettre en oeuvre des architectures orientees services de maniere simple en utilisant 
des services Web interapplicatifs. La technologie REST propose ainsi une solution de rechange interes- 
sante et plus simple au mode RPC et, dans la plupart des cas, a SOAP. 



Avec la technologie REST, les parametres font partie integrante de l'URI, comme l'illustre le 
code suivant avec un exemple d'URI contenant le parametre id : 

/<al i as-webapp>/<ressource-name>/{id} 

Spring 3.0 offre non seulement la possibilite d'ecrire des controleurs Web REST, mais 
propose aussi un composant client permettant d'effectuer des requetes REST, le RestTempl ate. 

Controleur Web REST 

Spring MVC offre la possibilite de passer en parametres des methodes des controleurs des 
valeurs en se fondant sur l'annotation PathVariable. Cette derniere fonctionne d'une maniere 
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similaire a Fannotation RequestParam en referencant les parametres presents dans Fadresse 
d'acces, comme l'illustre le code suivant (Q) : 

@RequestMapping(val ue = "/todo/{format}/{todoId}") 
public ModelAndView getTodo(@PathVari abl e String format, <— O 

OPathVariable String todold) { 

(...) 

} 

Avec REST, il est desormais possible d'utiliser d'autres methodes HTTP que celles utilisees 
habituellement dans les navigateurs par les applications Web classiques, a savoir les methodes 
GET et POST. Dans ce contexte, l'appel d'une ressource realisant la suppression d'une entite 
s'effectue avec la methode DELETE. La methode correspondante du controleur doit specifier 
la methode HTTP d'acces au niveau de l'annotation RequestMapping, comme dans le code 
suivant (Q) : 

@RequestMapping( 

value = Vtodo/ltodold} " , 

method = RequestMethod.DELETE^Q 

) 

public void deleteTodo(@PathVariable String todold, 
HttpServl etResponse response) { 
todoManager.remove(todoId) ; 
// pas de rendu de vue 

response. setStat us (HttpServl etResponse.SCJK) ; 

} 

L'appel de cette methode peut se realiser dans une page JSP par le biais de la balise form du 
taglib form de Spring, comme dans le code suivant (Q) : 

I <form:form method="del ete"><— Q 

<input type="submit" val ue="Supprimer un todo"/X/p> 
</form:form> 

En gardant le meme modele de programmation que celui de Spring MVC, le support REST de 
Spring permet de mettre en ceuvre REST de maniere interessante. Tous les mecanismes de 
Spring MVC sont utilisables dans ce contexte, contribuant d'autant a la simplicite de mise en 
ceuvre de cette technologie. 



Le RestTemplate 

Le RestTempl ate est la classe centrale du support client REST dans Spring. II permet d'effec- 
tuer des requetes HTTP selon les differentes methodes du protocole, tout en facilitant la 
gestion des reponses, avec la possibilite de transformer directement le flux de reponses en 
objets Java. 

Le RestTemplate fonctionne suivant la philosophie des templates d'acces aux donnees de 
Spring, dont les principes sont presentes au chapitre 10. II peut neanmoins etre utilise directe- 
ment, sans connaitre ces principes sous-jacents, l'essentiel consistant a savoir que le 
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RestTempl ate gere les connexions HTTP et laisse le developpeur se concentrer sur le code 
applicatif. 

Le RestTempl ate peut etre instancie de facon programmatique, mais il est plus judicieux de le 
declarer dans le contexte Spring, afin de profiter de l'injection de dependances, notamment 
pour de la configuration plus fine : 

<bean id="restTemplate" 

cl ass="org.springf ramework.web.cl ient. RestTempl ate" ><— © 
<property name=" request Factory") 

<bean class="org.springf ramework.http.cl ient.*» 

CommonsCl ientHttpRequestFactory" /><— Q 

</property> 
</bean> 

Le RestTempl ate est declare comme tout autre Bean, avec la classe correspondante (Q). Pour 
effectuer les acces HTTP, le RestTempl ate utilise une abstraction, la Cl ientHttpRequest- 
Factory, que Ton positionne avec la propriete requestFactory (Q). Nous utilisons dans notre 
exemple une implementation fondee sur la bibliotheque Jakarta Commons HttpClient, qui offre 
des possibilites interessantes de configuration (authentification, pool de connexions, etc.). 

Une fois configure, le RestTempl ate peut etre utilise pour recuperer le resultat d'une requete 
HTTP, par exemple pour appeler la methode getTodo du controleur REST de la section 
precedente : 

String xml = restTempl ate.getForObject( 

"http : //local host : 8080/rest/todo/ {f ormat }/{ todold} " ,<— O 

String, class, <—Q 

"xml","l");<-0 

La methode getForObject du RestTempl ate prend en premier parametre l'URL a appeler (©). 
On remarque l'utilisation de la syntaxe {nomParametre} pour indiquer les differents 
parametres ; dans notre cas, le format souhaite de la reponse (XML, HTML ou PDF) et l'iden- 
tifiant du Todo. Le deuxieme parametre de getForObject est la classe de retour attendue (Q). 
Le RestTempl ate est en effet capable de transformer le flux de la reponse en un objet Java. 

Par defaut, les transformations sont limitees (chaines de caracteres ou tableau d' octets), mais 
nous veiTons par la suite que ce mecanisme est parametrable. Dans notre exemple, nous nous 
contentons de recuperer la reponse sous forme de chaine de caracteres. La methode 
getForObject accepte en derniers parametres une liste variable d'objets, qui constituent les 
parametres a inserer dans la requete HTTP (©). 

La combinaison de l'URL demandee et des parametres fera que l'URL appelee sera la 
suivante : 

| http: //local host :8080/rest/todo/xml/l 

La reponse est bien sur geree par notre controleur REST, qui renvoie pour une telle requete un 
flux XML : 

<todo> 

<todo!d>K/todoId> 
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<description>todo K/description> 
<priority>K/pn'ority> 
<compl eted>true</compl eted> 
<hasNotes>true</hasNotes> 
</todo> 

La variable locale xml dans l'exemple ci-dessus contiendra done ce code XML. II est impor- 
tant de noter que l'utilisation du RestTempl ate n'est pas limitee a F interrogation de contro- 
leurs REST implemented par Spring MVC. La reponse pourrait tout aussi bien etre generee 
par un autre type de controleur Web, dans un langage different de Java. 

Nous venons de voir comment faire une requete GET (au sens HTTP du terme) avec le 
RestTempl ate. Celui-ci propose une API complete pour effectuer d'autres types de requetes, 
suivant les methodes du protocole HTTP. 

Nous pouvons effectuer une requete DELETE, par exemple, sur la methode del eteTodo de 
notre controleur : 

restTemplate.delete( 

"http: //local host :8080/rest/todo/ {todold} " , 
"1"); 

Cet appel va supprimer le Todo d'identifiant 1. Aucune reponse n'est attendue. 

Le tableau 7-5 recapitule les principales methodes disponibles dans le RestTempl ate. Remar- 
quez l'existence de la methode execute, qui, moyennant une utilisation plus complexe, permet 
de construire des requetes et d' exploiter les reponses pour des besoins avances, selon le prin- 
cipe des templates Spring. 



Tableau 7-5. Methodes du RestTemplate 



Methode HTTP 


Methode du RestTemplate 


DELETE 


deletetString, String, ...) 


GET 


delete(String, Class, String, ...) 


HEAD 


headForHeaderstString, String ...) 


OPTIONS 


optionsForAllowtString, String ...) 


POST 


postForLocationtString, Object, String ...) 


PUT 


puttString, Object, String ...) 


Toutes 


executetString, HttpMethod, RequestCal 1 back, ResponseExtractor, String...) 



Nous avons vu dans notre premiere utilisation du RestTemplate qu'il facilitait grandement 
1' appel de services REST, mais que sa gestion de la reponse etait relativement limitee : nous 
avons recupere un document XML sous forme de chaine de caracteres. Cette reponse contient 
les informations demandees, mais necessite une exploitation (analyse du code XML), qui 
s'avere fastidieuse si elle doit etre faite au niveau de l'appel. Lideal serait de recuperer l'objet 
metier attendu, e'est-a-dire une instance de Todo, le RestTempl ate prenant a sa charge la trans- 
formation. 
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Le RestTempl ate propose un mecanisme de convertisseur qui permet de controler tres flne- 
ment la conversion des objets Java qui lui sont passes ainsi que ceux qu'il renvoie. Nous allons 
ici nous interesser aux objets renvoyes, en convertissant le flux XML recu precedemment en 
un objet Todo. 

Cette conversion nous permettra d'effectuer l'appel suivant, pour lequel nous demandons et 
recuperons directement un Todo, plutot qu'un document XML : 

Todo todo = restTemplate.getForObject( 

"http: //local host :8080/rest/todo/{format}/{todold} " , 

Todo. class, 

"xmlVD; 

Pour arriver a ce resultat, il faut implementer un HttpMessageConverter, qui va se charger de la 
conversion de la reponse, puis Fassigner au RestTempl ate. 

Voici le code de F implementation de TodoHttpMessageConverter : 

package tudu. web. rest; 
(...) 

import org. springf ramework. http. HttpInputMessage; 
import org. springf ramework. http. HttpOutputMes sage; 
import org. springf ramework. http. Med iaType; 

import org. springf ramework. http. converter . HttpMessageConverter ; 

import tudu. domain. model .Todo; 

import com. though two rks .xst ream. XSt ream; 

public class TodoHttpMessageConverter 

implements HttpMessageConverter<Todo> { 

public Li st<Medi aType> getSupportedMediaTypest ) { 
return Col 1 ections .singl etonLi st( 
new Medi aTypet "text" , "xml " )<— O 

); 

1 

public boolean supports(Cl ass<? extends Todo> clazz) { 
return Todo.cl ass .equal s(cl azz) ;<— © 

1 

public Todo read(Class<Todo> clazz, 

HttpInputMessage inputMessage) 

throws IOException { 
XStream xstream = new XStreamO; 
xst ream. alias ("todo", Todo. class) ; 

return (Todo) xstream. fromXMKinputMessage. getBodyt )) ;<— © 

1 

public void write(Todo t, HttpOutputMessage outputMessage) 
throws IOException { 
throw new UnsupportedOperationException( ) ;<— © 

1 

} 
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Le role d'un HttpMessageConverter est d'effectuer des transformations d'objets Java vers des 
messages HTTP et inversement. II doit done indiquer le type de media qu'il est capable de 
gerer (Q) : dans notre cas les reponses de type text/xml, ainsi que la hierarchie de classes 
qu'il peut convertir (©), e'est-a-dire des Todos. 

La methode read nous interesse particulierement, car e'est elle qui se charge de la transforma- 
tion de la reponse en Todo. Nous recevons ici une representation XML d'un Todo, et nous utili- 
sons XStream pour la convertir en objet Java (©). XStream presente l'interet d'etre tres 
simple d'utilisation et concis, mais tout autre mecanisme de deserialisation aurait pu tout aussi 
bien convenir. L operation inverse, qui consiste a transformer F objet Java en message HTTP, 
ne nous interessant pas, elle n'est pas implemented (Q). 

Le convertisseur etant ecrit, il faut maintenant le positionner au sein du RestTempl ate, grace a 
sa propriete messageConverters, qui contient la liste de ses differents convertisseurs : 

<bean id="restTemplate" 

cl ass-"org.springf ramework.web.cl ient. RestTempl ate"> 
(...) 

<property name="messageConverters"> 
<list> 

<bean cl as s=" o rg. springf ramework. http. converter . 

By teAr ray HttpMessageConverter "/><—© 
<bean cl as s=" org. springf ramework. http. converter . *» 

StringHttpMessageConverter"/><— Q 
<bean cl ass="tudu. web. rest. TodoHttpMessageConverter" /><— Q 
</list> 
</property> 
</bean> 

Un RestTempl ate dispose de convertisseurs positionnes par defaut, qui gerent les conver- 
sions sous forme de chaines de caracteres ou de tableau d'octets. II faut les positionner 
explicitement des que nous parametrons la propriete messageConverters, afin que ces cas 
simples soient toujours geres (©). Notre convertisseur de Todo est lui parametre au 
repere Q. 

Le mecanisme de convertisseurs apporte au RestTempl ate une extensibilite et une adaptabilite 
tres interessantes, lui permettant de gerer la conversion des messages HTTP en objets Java, 
afin d'obtenir un code applicatif le plus epure possible. 



En resume 

Spring 3.0 apporte un support REST a Spring MVC. II devient alors possible d'implementer 
des controleurs REST en suivant le modele de programmation de Spring MVC, fonde sur les 
annotations. 

Le support client n'est pas en reste, avec le RestTempl ate, qui propose une API tres simple et 
extensible afin d'interroger des services REST (independamment de leur technologie) et 
d' exploiter au mieux leur reponse. 
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Mise en oeuvre de Spring MVC dansTudu Lists 

Les principaux concepts et composants de Spring MVC ayant ete introduits, nous pouvons 
passer a leur mise en pratique dans notre etude de cas. 

Configuration des contextes 

Le premier contexte renvoie a F application Web. II est charge avec le support de la classe 
ContextLoaderLi stener en utilisant les fichiers dont le nom correspond au pattern /WEB-INF/ 
applicationContext* .xml. 

Le second contexte est utilise par Spring MVC et est charge par la servlet Di spatcherServl et 
en utilisant le fichier action-servlet.xml localise dans le repertoire WEB-INF. Les differentes 
entites relatives a Spring MVC sont definies dans ce fichier. 

Cette servlet est configuree dans le fichier web.xml de F application Web, comme Fillustre le 
code suivant : 

<?xml version="1.0" encoding="UTF-8"?> 
<web-app> 
(...) 
<servl et> 

<servl et-name>action</servl et-name> 
<servl et-cl ass> 

org. spri ngf ramework.web.servl et . Di spatcherServl et 
</servl et-cl ass> 

<1 oad-on-startup>K/l oad-on-startup> 
</servl et> 

<servlet-mapping> 

<servl et-name>action</servl et-name> 

<url -pattern>*.action</url -pattern> 
</servlet-mapping> 
(...) 
</web-app> 

Dans le fichier action-servlet.xml suivant, Fapproche fondee sur les annotations a ete activee 
en se fondant sur la balise component-scan (0) de Fespace de nommage context (seuls les 
controleurs localises dans les packages dont le nom commence par tudu.web etant utilises) : 

<beans xml ns="http: //www. springframework.org/schema/beans" 
xml ns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns : context="http: //www. spri ngf ramework. org/ schema /context " 
xsi : schema Location-" 

http: //www. springframework.org/schema/beans 
http: //www. spri ngf ramework.org/schema/beans/spring-beans .xsd 

http: //www. springframework.org/schema/context 
http: //www. spri ngf ramewo rk.org/schema /*» 

context / s pr ing- context .xsd" > 

<context:component-scan base-package="tudu.web" /><— Q 

(...) 
</beans> 
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Commons Validator 

Le projet Spring Modules offre le support de Commons Validator, le framework d' Apache 
visant a specifier les regies de validation par declaration communement utilise avec Struts. 

Commons Validator se configure de la maniere suivante dans le cadre de Spring MVC : 

<bean id="val idatorFactory" class="org.springmodules. commons 

. val i da tor. Def aul tVal idatorFactory "> 
<property name="val idationConf igLocations"> 
<list> 

<val ue>/WEB- INF/ val idator- rul es .xml </val ue> 
<value>/WEB-INF/validation.xml</value> 
</list> 
</property> 
</bean> 

<bean id="beanVal idator" class="org.springmodules. commons 

.validator. Def a ultBeanVal idator"> 
<property name="val idatorFactory" ref-"val idatorFactory"/) 
</bean> 

Dans chaque controleur de gestion de formulaire, le Bean beanVal idator doit etre injecte par 
1' intermediate de Fannotation Autowi red. Le nom du Bean de formulaire utilise par le controleur 
permet de determiner la regie a utiliser de la configuration de la validation WEB-INF/valida- 
tion.xml. La methode val idate de ce Bean est ensuite utilisee arm de realiser la validation. 

Implementation des controleurs 

Au travers de 1' application Tudu Lists, differents mecanismes et types de controleurs sont 
implemented parle biais des annotations RequestMapping, Model Attribute et InitBinder decri- 
tes dans les sections precedentes. 

Les sections suivantes se penchent sur la facon dont sont mis en ceuvre des controleurs a 
entree multiple et de formulaire realisant respectivement un affichage de donnees et une 
gestion de formulaire HTML. La presentation associee a ces deux controleurs utilise les tech- 
nologies JSP/JSTL. 

Controleur simple 

Le controleur ShowTodosAction du package tudu. web dispose de traitements pour afficher les 
todos d'une liste. Comme l'illustre Fextrait de code ci-apres, il utilise Spring MVC a Faide 
des elements suivants : 

• Annotation Control 1 er au niveau de la classe (©) afin de preciser que cette derniere joue le 
role d'un controleur dans Spring MVC. 

• Annotation RequestMapping au niveau de la methode showTodos (Q) afin de definir le point 
d'entree. Plusieurs points d'entree peuvent etre specifies a ce niveau. 
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• Annotation RequestParam afin de recuperet - directement en tant que parametres du point 
d' entree les parametres de la requete Web. Dans notre cas, le parametre optionnel list Id 
(©) est pris directement dans la requete s'il est present. Dans le cas contraire, sa valeur vaut 
null. 

• Parametre de type Model Map (©) afin de manipuler les donnees du modele. Des ajouts dans 
ce dernier peuvent etre realises par Fintermediaire de la methode addAttri bute de la classe 
(©)■ 

• Type de retour afin de preciser la vue utilisee pour presenter les donnees (©). 
©Control 1 er<— © 

public class ShowTodosControl 1 er { 
(...) 

©RequestMappi ng( "/secure/showTodos .action" ) 
public String showTodos(<— © 

©Request Pa ram (val ue="l istld" , <— © 

requi red=f al se) String 1 istld, 

ModelMap model<— © 

) { 

log.debug("Execute show action"); 

Col lection<TodoList> todoLists = new TreeSet<Todol_ist>( 
userManager .getCur rent User ( ) .getTodoLi sts( ) ) ; 

if (! todoLists . i sEmpty( ) ) { 
if (listld != null ) { 

model . addAttri but e( "def aul t Li st" , 1 istld) ;<— © 
} else { 

model .addAttribute("defaultl_ist" , 

todoLists . iterator ( ) . next( ) .get Li stld( ) ) ;<— © 

} 

} 

return "todos";<— © 

} 

} 

Aucune configuration n'est requise dans le fichier WEB-INF/action-servlet.xml pour le 
controleur. Les configurations relatives a Spring MVC (©) et a Finjection de dependances 
(©) se realise directement dans la classe par Fintermediaire d' annotations, comme Fillustre 
le code suivant : 

©Control 1 er<— © 

public class ShowTodosControl 1 er { 
©Autowi red<— © 

private UserManager userManager; 
(...) 



@RequestMapping( "/secure/showTodos .action" )<—© 
public String showTodos( 
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@RequestParam( val ue-"l i stld" ,<— O 
requi red=f al se) String listld, 
ModelMap model 

(...) 

} 

} 

La maniere d'acceder aux points d' entree du controleur est definie dans les annotations 
RequestMapping. Aucune configuration supplemental n'est necessaire. Dans le cas precedent, le 
controleur ShowTodosController est accessible a partir de l'URI /secure/showTodos . action. 

Cette etude de cas met egalement en pratique le mecanisme de chainage de ViewResolver. 
Ainsi, retrouve-t-on dans le fichier /WEB-INF/action-servlet.xml la configuration de 
plusieurs ViewResolver : 

• Le premier est implemente par la classe ResourceBundl eVi ewResol ver, qui utilise le fichier 
de proprietes vi ews . properti es afin de configurer les vues. 

• Le deuxieme est implemente par la classe Xml ViewResolver, qui utilise le fichier /WEB- 
INF/views.xml pour configurer les vues. 

• Le dernier est implemente par la classe Internal ResourceViewResol ver, qui se fonde, dans 
notre cas, sur une vue JSP/JSTL. II constitue la strategie de resolution par defaut et est 
utilise dans le cas oil un identifiant de vue ne peut etre resolu par les deux entites precedem- 
ment decrites. 

La figure 7-12 illustre cette chaine en soulignant les identifiants des vues configurees dans les 
deux premiers ViewResolver. 



ViewResolver! 
(views. properties) 



Vues : register_ok, 
recover_password_ok, 
rssFeed 



ViewResolvei2 
(views.xml ) 



Vues : todol_lists_repori 
backup 



ViewResolveK3 
(JSP / JSTL) 



Vues : toutes les pages JSP 



Figure 7-12 

drainage des ViewResolver dans Tudu Lists 



Le controleur utilise la vue todos qui est resolue par le dernier ViewResolver et correspond 
done a la page JSP todos.jsp localisee dans le repertoire /WEB-INF/jsp/. 

Controleur de gestion de formulaire 

La mise en ceuvre d'un controleur de gestion de formulaire n'est guere plus complexe que 
celle d'un controleur simple : un Bean est utilise pour les donnees du formulaire, et deux 
points d'entree doivent etre definis, un pour le chargement du formulaire, 1' autre pour sa vali- 
dation. 
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Detaillons le controleur MylnfosController du package tudu.web, qui permet de modifier les 
informations d'un utilisateur de 1' application. 

Comme l'illustre l'extrait de code ci-apres, ce controleur utilise Spring MVC a Faide des 
elements suivants : 

• Annotations Control 1 er et RequestMappi ng au niveau de la classe afin de definir la classe en 
tant que controleur et FURI d'acces a ce dernier (Q). 

• Methode showForm (Qi) appelee par F intermediate d'une methode GET et configuree avec 
l'annotation RequestMappi ng. Cette methode a la responsabilite de charger les donnees du 
formulaire. 

• Methode submitForm (©) appelee afin de traiter les donnees soumises par le formulaire 
avec la methode HTTP POST et configuree avec l'annotation RequestMappi ng. 

• Utilisation explicite de la validation Commons Validator dans le corps de la methode 
submitForm (©). 

• Specification des vues utilisees pour l'affichage suite a la soumission du formulaire par 
l'intermediaire des retours des deux methodes precedentes (©). 

©Control 1 er<— © 

©RequestMappi ng( "/secure/my infos .action" ) 
public class MylnfoControl 1 er { 
(...) 

@RequestMapping(method = RequestMethod.GET) 
public String showForm(HttpServl etRequest request, <—Q 
Model Map model ) { 

String login = request. getRemoteUser( ) ; 

User user = userManager.findLlser(login) ; 

UserlnfoData data=new UserInfoData( ) ; 

data .setPassword( user .get Password ( ) ) ; 

data .setVerify Password (user .get Pas sword ( ) ) ; 

data .setFi rstName( user .get Fi rstName( ) ) ; 

data . set La st Name (user .get Last Name ( ) ) ; 

data.setEmail (user.getEmail ( ) ) ; 

model .addAttributeC'userinfo" , data) ; 

return "userinfo" ;<— Q 

} 



©RequestMappi ng ( met hod=RequestMet hod. POST) 
public String submi tForm(<— Q 

HttpServl etRequest request, 

©Model Attribute( "userinfo" ) UserlnfoData userinfo, 
BindingResult result) { 

beanVal idator.val i date (user Info, result) ;<— Q 
if ( [result. hasErrorsO) {<— © 

String password = userinfo. getPassword( ) ; 

String firstName = userinfo. getFi rstName( ) ; 

String lastName = userinfo. getLastName( ) ; 
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String email = userlnfo.getEmail ( ) ; 
String login = request .getRemoteUser( ) ; 
User user = userManager.findUser(login) ; 
user. set Pas sword (password) ; 
user . set Fi rstName(f i rstName) ; 
user . set Last Named astName) ; 
user.setEmail (email ) ; 
userManager . updateUser(user) ; 



Aucune configuration n'est requise dans le fichier WEB-INF/action-servlet.xml pour le 
controleur. Comme le montre le code suivant, les configurations relatives a Spring MVC (Q) 
et a Finjection de dependances (Qi) se realisent directement dans la classe par Fintermediaire 
d' annotations : 

©Control 1 er<— Q 
public class Mylnf oControl 1 er { 
@Autowi red<— Q 

private UserManager userManager; 
@Autowi red<— Q 

private DefaultBeanValidator beanVal idator; 



(...) 

} 

@RequestMapping(method=RequestMethod. P0ST)<— Q 
public String submitForm( 

HttpServl etRequest request, 

@ModelAttribute("userinfo") UserlnfoData userInfo,<— Q 
BindingResult result) { 
(...) 

} 



La maniere d'acceder aux points d' entree du controleur est definie dans les annotations 
RequestMapping. Aucune configuration supplementaire n'est necessaire. Dans Fexemple 
precedent, le controleur MylnfoController est accessible a paitir de FURI /secure/ 
myi nf os .action par Fintermediaire des methodes GET et POST. 



return "userinfo" ;<— Q 



(...) 



@RequestMapping(method = RequestMethod.GETX— O 
public String showForm(HttpServl etRequest request, 
ModelMap model ) { 
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Les donnees du formulaire soumises peuvent etre validees par le biais de l'abstraction 
Validator vue precedemment, et plus particulierement les implementations constituant le 
support de Commons Validator, qui permet de reutiliser les regies de validation userinfo. 

Le controleur utilise la vue user_i nf o dans le but d'afficher le formulaire dans les cas d'echec 
ou de succes lors de la validation. Cette vue est resolue par le dernier ViewResolver de la 
chaine et coirespond done a la page JSP user_info. jsp localisee dans le repertoire /WEB- 
INF/jsp/. Cette page doit etre modifiee afin de remplacer les taglibs de gestion des formulaires de 
Struts par ceux de Spring MVC. 

Comme l'illustre le code suivant, le framework met en ceuvre le taglib form afin de remplir les 
champs du formulaire (Q) et d'afficher les eventuelles erreurs de validation (Q) : 

(...) 

<form:form model Attribute="userinfo" focus="f i rstName"> 
<font color="red"> 

<b><form:errors path="*"/X/b> 
</font> 
(...) 

<form:input path="f i rstName" size-"15" maxl ength="60"/><— O 
 <font color="red"> 

<form:errors path="fi rstName"/X/font><— Q 

(...) 

<input type="submit" value="<fmt:message key="form.submit"/>"/> 
<input type="button" 

oncl ick=" document . 1 oca t ion. href =' <c: url 

val ue=" . . /wel come.action"/> ' ; " 
val ue="<fmt : mess age key=" form. cancel "/>"/> 
</form> 

Le controleur affiche la page de formulaire suite au succes de la soumission des donnees par 
Fappel de la methode showForm dans la methode onSubmit. Lutilisation d'une autre vue grace 
aux methodes setSuccessView et getSuccessView serait aussi possible. 



Implementation de vues specif iques 

Tudu Lists utilise plusieurs technologies de presentation afin de generer differents formats de 
sortie (HTML, XML, RSS, PDF). Spring MVC offre une infrastructure facilitant leur utilisation 
conjointement dans une meme application. 

Dans la mesure ou Fentite Vi ewResol ver utilisee precedemment pour les vues utilise les techno- 
logies JSP et JSTL, elle ne peut servir pour les vues decrites ci-dessous. Dans les sections 
suivantes, nous utiliserons done F implementation Xml Vi ewResol ver afin de les configurer. 

XML 

L application Tudu Lists permet de sauvegarder au format XML les informations contenues 
dans une liste de todos. Cette fonctionnalite est implementee par le controleur Backup- 
TodoLi stControl 1 er du package tudu .web, qui a la responsabilite de charger la liste correspondant 
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a l'identifiant specifie puis de la placer dans le modele afin de la rendre disponible lors de la 
construction de la vue. 

Ce controleur dirige les traitements vers la vue ayant pour identifiant backup a la fin de ses 
traitements. Cette vue, implementee par la classe BackupTodoListView du package tudu.web, 
est resolue par le second ViewResol ver de la chaine. 

Sa configuration se trouve dans le fichier views.xml localise dans le repertoire WEB-INF. 
Elle utilise le support de la classe AbstractXsl tVi ew de Spring MVC afin de generer une sortie 
XML, comme dans le code suivant : 

public class BackupTodoListView extends AbstractXsltView { 
(...) 

protected Node createDomNode(Map model, 

String rootName, HttpServl etRequest request, 
HttpServl etResponse response) throws Exception { 

TodoList todoList = (TodoList)model .getC'todoList") ; 
Document doc = todoListsManager.backupTodoList(todoList) ; 
return new D0M0utputter( ) .output( doc ); 

} 

} 

A la fin de l'execution de la methode createDomNode, la classe BackupTodoListView rend la 
main a sa classe mere afin de realiser eventuellement une transformation XSLT et d'ecrire le 
contenu sur le flux de sortie. 

L'utilisation de XmlViewResolver permet d'injecter une instance du composant TodoLists- 
Manager dans la classe de la vue, comme decrit dans le fichier views.xml suivant : 

<bean id="backup" class="tudu.web.BackupTodoListView"> 

<property name-"todoListsManager" ref="todoLi stsManager"/> 
</bean> 

PDF 

L' application de F etude de cas permet egalement de generer un rapport au format PDF avec 
les informations contenues dans une liste de todos. Cette fonctionnalite est implementee par 
l'intermediaire du controleur ShowTodoListsReportController du package tudu.web, qui a la 
responsabilite de charger la liste correspondant a l'identifiant specifie puis de la placer dans le 
modele afin de la rendre disponible lors de la construction de la vue. 

Ce controleur dirige les traitements vers la vue ayant pour identifiant todo_l i sts^report a la 
fin de ses traitements. Cette vue, implementee par la classe ShowTodoLi stsPdfVi ew du package 
tudu.web, est resolue par le second ViewResol ver de la chaine. 

Sa configuration se trouve dans le fichier views.xml localise dans le repertoire WEB-INF. 
Elle utilise le support de la classe AbstractPdfView de Spring MVC afin de generer une sortie 
PDF par le biais du framework iText, comme dans le code suivant : 

public class ShowTodoListsPdfView extends AbstractPdfView { 
protected void bui 1 dPdf Document( 
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Map model, Document doc, 

PdfWriter writer, HttpServl etRequest req, 

HttpServl etResponse resp) throws Exception { 

TodoLi st todol_ist=(Todol_ist)model . get( "todol ist" ) ; 

doc. add (new Paragraph(todol_i st .get Li stld( ) ) ) ; 
doc . add (new Paragraph(todol_ist .getName( ) ) ) ; 
(...) 

} 

} 

La classe mere de la classe ShowTodoListsPdfView a la responsabilite d'instancier les differen- 
tes classes de iText afin de les lui fournir. A la fin de 1' execution de la methode 
buildPdf Document, la classe ShowTodoListsPdfView rend la main a sa classe mere pour ecrire le 
contenu sur le flux de sortie. 

Notons que cette vue aurait pu aussi bien etre configuree dans le fichier views.properties, 
puisqu'elle ne necessite pas d'injection de dependances. 



Conclusion 

Pour mettre en ceuvre le patron de conception MVC, Spring MVC offre une approche interes- 
sante fondee sur les mecanismes d'injection de dependances et les metadonnees configurees 
dans des annotations. 

Les principaux atouts du framework resident dans son ouverture ainsi que dans la modularite 
et l'isolation des composants du patron MVC. Le developpement des applications utilisant 
differentes technologies s'en trouve facilite, et le changement de briques n'impacte pas le 
reste de 1' application ni 1' extension du framework. 

L utilisation de F injection de dependances de Spring dans F implementation du pattern MVC 
permet de configurer avec une reelle facilite ces differents composants ainsi que leurs depen- 
dances. Cette configuration est centralisee dans le contexte applicatif de Spring, lequel peut de 
la sorte mettre a disposition toute la puissance du conteneur leger. 

Spring MVC propose une approche fondee sur les annotations afin d'implementer les contro- 
leurs. Introduite avec la version 2.5 du framework, cette approche d'une grande facilite 
d'utilisation permet de s'abstraire de FAPI Servlet. Le framework propose ainsi une gestion 
des formulaires d'une flexibilite remarquable. 

Le framework Spring MVC propose enfin une separation claire entre le controleur et la vue 
ainsi qu'un support pour les differentes technologies et frameworks de presentation. 

En resume, ce framework fournit un socle solide pour developper des applications Web sans 
donner la possibilite d'abstraire la navigation et Fenchainement des pages. Un framework tel 
que Spring Web Flow, presente en detail au chapitre suivant, peut s'appuyer sur ce socle afin 
de resoudre cette problematique. 
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Certaines applications Web necessitent un enchainement defini d'ecrans afin de realiser leurs 
traitements. Elles doivent de plus empecher Futilisateur de s'ecarter des enchainements possi- 
bles et garder un contexte relatif a F execution. Lorsqu'une application repond a ces criteres, 
la mise en ceuvre d'outils tels que Spring Web Flow est pertinente. Ce type de framework ne 
presente en revanche aucun interet dans le cas d' applications pour lesquelles la navigation est 
libre. 

Le present chapitre debute par F explication des concepts de flots Web. II se poursuit par une 
presentation detaillee des fonctionnalites proposees par le principal module de Spring Web 
Flow (configuration, cycle de vie d'un flot, securisation, etc.). II s'acheve par une implemen- 
tation simplified de F etude de cas Tudu Lists. 

Concepts des flots Web 

Lobjectif des flots Web est d'implementer des traitements qui comprennent plusieurs etapes 
et diverses contraintes pour passer d'une page a une autre. 

Dans le cas d' applications Java EE, ces etapes se materialised par des interactions avec le 
serveur. 

La conception et la mise en ceuvre d' applications pour lesquelles la navigation se trouve 
restreinte et predefinie par des regies precises se revelent particulierement complexes, et ce 
pour les raisons suivantes : 

• La configuration des enchainements de traitements est difficile. 

• La verification de la validite des enchainements est complexe a mettre en ceuvre. 
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• La session HTTP n'est pas entierement adaptee pour stacker les donnees d'un flot de trai- 
tements. 

• La reutilisation des differents flots Web est complexe a implemented 

Ces constats mettent en exergue les enjeux suivants, que F architecture et la conception de ce 
type d' application doivent resoudre de maniere optimale : 

• decouplage des flots et de leur implementation ; 

• gestion des donnees des etats du flot de traitements ; 

• respect des contraintes du flot par une entite autonome ; 

• favorisation de la reutilisation des flots Web ; 

• integration des flots Web dans Fenvironnement technique existant. 

Pour resoudre ces problematiques et adresser au mieux les enjeux precedemment decrits, 
Fapproche adequate consiste a integrer un moteur d' execution de flots Web utilisant une 
description des flots. 

L utilisation de ce type de moteur dans une application offfe les avantages suivants : 

• definition centralisee des elements du flot et de leurs enchamements ; 

• configuration du flot fondee sur une grammaire XML dediee, lisible aussi bien par un 
concepteur, un developpeur ou un environnement de developpement (IDE) ; 

• notion de transitions mise en ceuvre dans la configuration du flot afin de cadrer et securiser 
la navigation ; 

• gestion systematique par le moteur des etats en interne ; 

• suppression des dependances avec la technologie sous-jacente et le protocole utilise ; 

• configuration des flots facilement integrable dans un IDE ; 

• gestion du cycle de vie du flot facilitee et integree au moteur sans aucun impact sur les flots 
Web. 

Detaillons maintenant plus en detail les problematiques liees aux flots et automates a etats 
finis ainsi que leurs diverses composantes. 



Definition d'un flot Web 

Un flot Web s'inscrit dans la problematique generale des AEF (automate a etat fini). Ces auto- 
mates permettent de specifier les differents etats accessibles des flots ainsi que la maniere de 
passer des uns aux autres. lis peuvent etre facilement decrits en UML dans des diagrammes 
d'activite avec des entites stereotypees, comme l'illustre la figure 8-1. 

Un flot est done caracterise par un ensemble fini d' etats possibles, dont certains peuvent etre 
initiaux et d' autres finaux. L' execution ne peut se poursuivre que par le biais de transitions 
d'un etat vers une liste d' etats connue et finie. 

Les etats initiaux et finaux exceptes, un etat est accessible depuis un ensemble d' etats suite au 
declenchement de differents evenements et peut transiter vers d' autres etats suite au declen- 
chement d' autres evenements. 
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Figure 8-1 

Diagramme UML 
d'unflot Web 




La figure 8-2 illustre les differentes composantes d'un etat. 



Figure 8-2 

Composantes d'un etat 
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Le passage d'un etat a un autre s'effectue par le biais d'une transition, qui decrit I'etat a acceder 
suite au declenchement d'un evenement sur un autre etat. Propriete d'un etat, une transition 
regroupe l'evenement declencheur ainsi que I'etat a executer dans ce cas. 



Les types d'etats 

Au sein d'un flot d' execution, plusieurs types d'etats peuvent etre mis en ceuvre afin d'adresser 
differentes problematiques : 

• Debut et fin. Les etats de debut et de fin d'un flot correspondent a des etats particuliers. Un 
etat de debut ne peut avoir d'etat 1' appelant, et un etat de fin ne doit pas posseder de transi- 
tion en sortie. Ces types d'etats peuvent aussi bien etre des etats d'affichage de vue que de 
declenchement d'actions, ne possedant done pas de stereotype specifique. 

• Affichage de vue. Un etat peut correspondre a l'affichage d'une vue. II doit dans ce cas lui 
faire reference. Les differents evenements declenches par la vue doivent etre definis sur 
I'etat en tant que transitions. Ce type d'etat est designe par les termes « View State ». Nous 
utilisons le stereotype View State pour le representer. 

• Execution d' action. Un etat peut correspondre au declenchement d'une methode d'une 
action, quel que soit son type. II doit dans ce cas definir les differents evenements a declen- 
cher que peuvent retourner ces methodes. Ce type d'etat est designe par les termes « Action 
State ». Nous utilisons le stereotype Action State pour le representer. 
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• Aiguillage. Un etat peut correspondre a un aiguillage fonde sur une ou plusieurs conditions 
afin d'acceder a d'autres etats. Ce type d'etat est designe par les termes « Decision State ». 
Nous utilisons le stereotype Decision State pour le representee 

• Lancement de sous-flots d' execution. Un etat peut declencher F execution d'un sous-flot de 
traitement et permettre le passage de parametres d'un flot a un autre. Ce type d'etat est 
designe par les termes « Sub Flow State ». Nous utilisons le stereotype Sub Fl ow State pour 
le representee 



En resume 

Nous avons decrit dans cette section les differents concepts des flots Web dont Spring Web 
Flow constitue une implementation. Nous avons egalement aborde les notions d'etat et de 
transition utilisees dans ces flots. 

Les sections suivantes decrivent les mecanismes du framework Spring Web Flow permettant 
d'implementer cette problematique. 



Mise en oeuvre de Spring Web Flow 

La distribution de Spring Web Flow peut etre telechargee a partir de la page de son site : 
http://springframework.org/webflow. Nous nous referons dans ce chapitre a la version 2.0.7 de 
Spring Web Flow, qui necessite Spring dans sa version 2.5.4 ou ulterieure. 

Depuis sa version 2, le projet Spring Web Flow est distribue avec deux autres modules. 
La figure 8-3 illustre 1' architecture generate de la distribution de Spring Web Flow. 



Figure 8-3 
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Spring Web MVC 



Spring Web MVC est une base essentielle de Spring Web Flow. Voici les differents modules 
qui constituent la distribution : 

• Spring Web Flow : permet la definition de flots Web a partir d'un langage de configuration 
dedie, appele DSL (Domain Specific Language), ainsi que leur execution. 
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• Spring JavaScript : framework proposant une abstraction pour la manipulation de 
JavaScript. Fonde sur Dojo. 

• Spring Faces : permet l'utilisation de JSF comme technologie de vues, aussi bien pour les 
applications Spring Web MVC que Spring Web Flow. 

Les sections qui suivent detaillent la configuration de Spring Web Flow (les deux autres 
modules ne sont pas abordes, car ils ne traitent pas directement des Hots Web) ainsi que la 
conception et 1' implementation des Hots Web fondes sur ce framework. 

Configuration du moteur 

Nous allons voir dans un premier temps une configuration minimale de Spring Web Flow et la 
definition d'un Hot simple. Dans cette configuration, Spring Web Flow repose sur une base 
Spring Web MVC tres fine. Nous verrons ensuite une configuration plus avancee, permettant 
de faire cohabiter une application Spring Web MVC et des Hots geres par Spring Web Flow. 
Ces deux configurations donnent un premier apercu de Spring Web Flow et permettent 
d'aborder plus facilement les concepts avances. 

Configuration minimale 

Le flot implemente lors de cette configuration est celui illustre a la figure 8-4. II s'agit d'un 
not commencant par une page d'accueil, proposant soit la visualisation d'une publicite, soit le 
passage direct a un menu. La page de publicite propose aussi un lien permettant de se rendre 
vers le menu. 



La configuration minimale passe par le positionnement dans le fichier web.xml d'une 
Di spatcherServl et, < Q et Q), point d'entree de Spring Web MVC : 

<?xml version="1.0" encoding="UTF-8"?> 
<web-app (...) > 

<di spl ay-name>Simpl est Web Fl ow</di spl ay-name> 



Figure 8-4 

Flot Web d'accueil 




<servl et> 

<servl et-name>swf </servl et-name><— Q 
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<servl et-cl ass> 

org.springf ramewor k. web. servlet.Di spat cherServ let <— © 
</servl et-cl ass> 
</servl et> 

<servl et-mappi ng> 

<servl et-name>swf</servl et-name> 
<url -pattern>/fl ow/*</url -pattern><— Q 
</servlet-mapping> 

</web-app> 

La DispatcherServlet positionnee va intercepter toutes les requetes HTTP commencant 
par If 1 ow/ (Qi). Comme indique au chapitre 7, dedie a Spring MVC, la Di spatcherServl et portant 
le nom swf (©) est configuree par le fichier swf-servlet.xml. Voici le contenu de ce fichier : 

<?xml version="1.0" encoding="UTF-8"?> 
<beans 

xmlns=" http://www.spri ngframework.org/schema/beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xml ns :webf 1 ow="http: //www. spri ngframework.org/schema/webfl ow-conf i g"<— O 
xsi :schemaLocation=" 

http: //www. springframework.org/schema/beans 
http:/ /www. springframework.org/schema/beans/spri ng - beans .xsd 
http: //www. springframework.org/schema/webfl ow-conf ig 
http: //www. springframework.org/schema/webfl ow-conf ig/ 
spri ng-webfl ow-conf ig-2.O.xsd"><—0 

<bean name="/*"<— Q 
cl as s-" org.springf ramewor k.webf 1 ow.mvc .servl et . Fl owControl 1 er"> 
<property name="f 1 owExecutor" ref="fl owExecutor" /> 
</bean> 

<webf 1 ow:f 1 ow- executor id="f 1 owExecutor" 
flow-registry="f 1 owRegistry" /><— Q 

<webf 1 ow: f 1 ow- regi stry id="f 1 owRegi stry"><— Q 
<webflow: flow- location- pattern 
value="/WEB-INF/flows/*-flow.xml " /><-© 
</webf 1 ow: f 1 ow-regi stry> 

</beans> 

Spring Web Flow dispose d'un schema XML pour la configuration de son moteur. II est posi- 
tionne en debut de fichier < Q et Q) et permet la definition des elements courants de Spring 
Web Flow. 

Comme pour une application Spring MVC, la Di spatcherServl et delegue les traitements a un 
controleur. Ce dernier est un Fl owControl ler, fourni par Spring Web Flow (©). II a besoin 
pour fonctionner d'un executeur, qui lui est injecte. Lexecuteur est defini au repere Q via une 
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balise dediee. II permet l'execution des flots Web et constitue le point d'entree dans le systeme 
de Spring Web Flow. II necessite pour fonctionner un registre de flots qui est defini au 
repere 0. Le registre charge les flots a partir d'un ensemble de fichiers dont le motif est decrit 
au repere Q Tous les fichiers du repertoire WEB-INF/flows terminant par -flow.xml seront 
charges. 

Le fichier correspondant a notre flot se trouve dans ce repertoire et se nomme simplest- 
flow.xml. Voici son contenu : 

<?xml version="1.0" encoding-"UTF-8"?> 

<fl ow xml ns="http: //www. spri ngframework.org/schema/webfl ow" 
xmlns:xsi="http: //www. w3.org/2001/XMLSchema -instance" 
xsi :s enema Locati on="http: //www. springframework.org/schema/webfl ow 
http : //www. springf ramework.org/ schema /webflow/spring-webf low- 2. 0.xsd"><—0 

<view-state id="wel come"><— Q 

<transition on="next" to="advertising" /><— Q 

<transition on-"skip" to="menu" /> 
</view-state> 

<vi ew- state i d=" advert i si ng"><— Q 

<transition on="next" to="menu" /> 
</view-state> 

<view-state id="menu" /> 

</flow> 

Spring Web Flow propose un schema XML pour la definition des flots (Q), le fichier 
simplest-flow.xml n'est done ni plus ni moins qu'un fichier de contexte Spring. Letat de 
debut est le premier defini dans le fichier (Q) ; il a pour identifiant wel come. II s'agit d'un etat 
affichant une vue (balise view- state). Nous verrons par la suite que cette vue contient deux 
liens qui permettent de provoquer les deux transitions de Fetat (balises transition). La 
premiere transition (0) provoque le passage a l'etat advertising (©), qui est lui aussi une 
vue. 



Langage de programmation specialise 

Le schema XML de Spring Web Flow permet de rendre la definition de flots tres simple (avec un editeur 
XML adapte, proposant de la completion) et tres lisible. C'est Tun des avantages des schemas XML intro- 
duits dans Spring 2.0. Le langage de configuration de flots de Spring Web Flow peut etre qualifies de 
langage de programmation specialise (Domain Specific Language), puisqu'il n'a d'utilite que pour la defi- 
nition de flots. 

Les langages de programmation specialises sont apprecies par les programmeurs pour leur concision et 
leur efficacite. Cependant un langage de programmation specialise peut aussi etre destine a un public non 
technique, expert dans un domaine fonctionnel et qui peut retrouver dans le langage toutes les notions de 
son domaine, sans devoir prendre en main un langage plus puissant et generaliste (comme Java), mais 
beaucoup plus technique. 
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Dans cette configuration minimale, pour les etats correspondant a un affichage de vue, Spring 
Web Flow utilise Fidentifiant pour determiner le nom du fichier correspondant a la vue. Par 
defaut, Spring Web Flow va chercher un fichier dans le repertoire de definition du flot et utili- 
ser un fichier JSP. Dans notre exemple, les trois fichiers de vue se trouvent dans le repertoire 
WEB-INF/flows et se nomment welcome.jsp, advertising.jsp et menu.jsp. 

Voici le contenu du fichier welcome.jsp : 

<p><a href="${f 1 owExecutionUrl }&_eventId=next">Adverti sing</a></p> 
<p><a href="${flowExecutionUrl }&_eventId=skip">Go to menu</a></p> 

Ce fichier contient les deux evenements qui provoquent les deux transitions de l'etat wel come. 
Ces deux evenements sont des liens hypertextes. Spring Web Flow propose une variable 
fl owExecutionUrl permettant de recuperer facilement 1'URL du flot courant. Les codes des 
deux transitions possibles sont indiques par le parametre HTTP _eventld. 

Si l'utilisateur clique sur le premier lien genere, il est renvoye vers l'etat adverti si ng et done 
la vue advertising.jsp : 

<p>Some advertising</p> 

<pXa href="${fl owExecutionUrl }&_eventId=next">Menu</aX/p> 

L'utilisateur peut cliquer sur le lien pour aniver au dernier etat, etat qu'il aurait pu atteindre en 
cliquant sur le deuxieme lien de la premiere vue. Voici le contenu de la vue de l'etat menu, 
menu.jsp : 

<p>Welcome to the menu</p> 

Notre flot etant completement defini, il s'agit maintenant de l'executer. Pour cela, il faut 
lancer l'application et, si notre application a pour contexte simplestwebflow, appeler FURL 
suivante : 

http://localhost:8080/simplestwebflow/flow/simplest-flow 

La DispatcherServlet intercepte les requetes de la forme /flow/* et le Fl owControl 1 er attend 
dans l'URL le nom du flot a executer. Spring Web Flow supprime l'extension du fichier de 
definition du flot pour definir l'identifiant du flot. 

La configuration minimale de Spring Web Flow est done relativement simple. Cependant, les 
applications utilisent generalement Spring Web Flow conjointement a un framework Web, par 
exemple Spring MVC. Nous allons voir a la section suivante comment faire cohabiter Spring 
Web Flow avec des controleurs Spring MVC. 

Configuration dans une application Spring MVC 

La configuration d'une application Web Spring utilisant Spring Web Flow commence par le 
chargement d'un contexte Spring Web et d'une Di spatcherServl et. Cette configuration se fait 
dans le fichier web.xml : 

<?xml version="1.0" encoding="UTF-8"?> 
<web-app (...) > 
<di spl ay-name>Tudu Spring Web Flow</display-name> 



Spring Web Flow M 

<context-param> 
<param-name>contextConf i gLocation</param-name> 
<param-val ue>/WEB- INF/appl i ca ti on- context .xml </param-val ue><— Q 

</context-param> 

<1 istener> 

<1 i stener-cl ass> 
org.springf ramework. web. con text .Context Loader Lis tener<—Q 

</l i stener-cl ass> 
</l istener> 

<servl et> 

<servlet-name>Spring MVC Dispatcher Servl et</servl et-name> 
<servlet-class> 

o rg. springf ramework. web. servl et.Di spa tcherServl et<— © 
</servl et-cl ass> 
<init-param> 

<param-name>contextConf igLocation</param-name> 

<param-val ue> 

/WEB- INF/web- appl ication-config.xml<— Q 

</param-val ue> 
</init-param> 
</servlet> 

<servlet-mapping> 

<servlet-name>Spring MVC Dispatcher Servl et</servl et-name> 

<url -pattern>*.htm</url -pattern> 
</servl et-mappi ng> 

</web-app> 

Le contexte Spring de l'application est charge grace au ContextLoaderListener (Q), a partir 
du fichier /WEB-INF/application-context.xml. Ce contexte contient generalement la defini- 
tion des services metier, avec tous les elements dont ils dependent (connexion a la base de 
donnees, DAO, etc.). Les beans definis seront visibles par le contexte de la Di spatcherServl et 
(©X qui pourra y faire reference, car il existe une relation hierarchique entre le contexte Web 
et le contexte de la Di spatcherServl et. 

Le contexte de la servlet est charge a partir du fichier /WEB-INF/web-application- 
conflg.xml, qui contient la configuration de Spring MVC : 

<?xml version="1.0" encoding="UTF-8"?> 
<beans (...) > 

<context:component-scan base-package="tudu.web" /><— Q 

<bean cl ass=" org. springf ramework. web. servl et.mvc. annotation. 
AnnotationMethodHandl er Adapter" /><— Q 



<bean cl a ss=" org. springf ramework. web. servl et.mvc. 
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Simp! eControl 1 erHandl erAdapter"/><— Q 

<bean id="viewResolver" 

class="org.springframework.web.servlet.view. 
Internal ResourceViewResol ver"><— Q 
<property name="viewCl ass" 

val ue-"org.springframework.web.servlet. view. Jstl View" /> 
<property name="pref ix" val ue="/WEB- INF/jsp/" /> 
<property name="suf f ix" value=".jsp" /> 
</bean> 

<bean id="messageSource" 

cl a ss=" org. springframework. context. support. 
ResourceBundl eMessageSource"><— Q 
<property name="basename" val ue="tudu. web. Messages" /> 
</bean> 

<import resource="swf-application-config.xml " /><— Q 
</beans> 

Les controleurs de F application sont automatiquement detectes (Q) a partir du package 
tudu.web. II peut aussi bien s'agir de controleurs Spring MVC que de beans destines a Spring 
Web Flow (qui ne sont pas, comme nous le verrons par la suite, des controleurs a proprement 
parler). 

Voici un exemple d'un tel controleur Spring MVC (pour plus d' informations, se referer au 
chapitre traitant de Spring MVC) : 

u.web; 

springframework. stereotype .Control 1 er ; 
springframework. web. bind. annotation. RequestMapping; 

©Control 1 er 

public class Wei comeControl 1 er { 

@RequestMapping( "/wel come. htm" ) 
public String welcomeO { 
return "welcome"; 

} 

} 

Le contexte de la DispatcherServlet declare deux Handl erAdapters, qui gerent la delegation 
aux controleurs adaptes (repere Q pour les controleurs annotes de Spring MVC et repere Q 
pour les conttoleurs implementant Control 1 er, comme celui de Spring Web Flow). 

Le contexte definit aussi un ViewResol ver, qui gere la redirection vers les vues adaptees (0). 
Celui-ci gere des vues JSP, se trouvant dans le repertoire /WEB-INF/jsp. L'internationalisation 
est geree via un fichier de proprietes (©). 



package tud 

import org. 
import org. 
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La configuration de Spring Web Flow n'est pas effectuee directement dans ce fichier, mais par 
l'inclusion d'un fichier dedie (0). Voici le contenu du fichier swf-application-config : 

<?xml version="1.0" encoding="UTF-8"?> 
<beans (...) > 

<bean name="/flow/*.htm"<— Q 

class-" org. spn'ngframework.webflow.mvc.servlet.FlowController"> 

<property name="f 1 owExecutor" ref="fl owExecutor" /> 
</bean> 

<webflow:flow-executor id="fl owExecutor" /><— Q 

<webf 1 ow: fl ow-regi stry i d— "f lowRegi stry" 

f low-bui lder-servi ces="f 1 owBui 1 derServices"><— Q 
<webf low: flow -location -pattern 

value="/WEB-INF/flows/*-flow.xml" /> 
</webf 1 ow:f 1 ow-regi stry> 

<webf 1 ow: f 1 ow-bui 1 der- services id="fl owBui IderServi ces" 



<bean id="mvcViewFactory Creator" 

cl ass-" org. springframework.webflow.mvc. builder. 
MvcViewFactoryCreator"><— Q 
<property name="viewResolvers" ref="viewResolver" /> 
</bean> 



Nous retrouvons des elements de la configuration minimale, le FlowController (Q) et 
l'executeur de flot (Q). Le FlowControl ler a pour nom /flow/*. htm, ce qui signifie qu'il trai- 
tera les requetes HTTP de cette forme. 

Le registre de flots charge toujours un ensemble de fichiers, exactement comme dans la confi- 
guration minimale (©). Mais il fait maintenant reference a un Bean, flowBui IderServi ces, 
qui gere le parametrage d'un ensemble de services pour l'execution des flots. 

Le service que nous allons parameter est celui de resolution des vues (Q et Qi). Le 
MvcViewFactoryCreator utilise le ViewResolver parametre dans le fichier web-application- 
config.xml et effectue done le passage ente le monde Spring MVC et le Spring Web Flow 
pour Faffichage des vues. 

Avec cette configuration, un etat affichant une vue peut preciser un identifiant de vue via 
l'attribut view : 



view-factory-creator="mvcViewFactory Creator" /><— Q 



</beans> 



<view-state id-"show.todolists" view="todolists"> 
Lidentifiant de vue todol i sts fait ici reference au fichier /WEB-INF/jsp/todolists.jsp. 
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Conformement a la configuration de la DispatchServlet, au nom du FlowController et a la 
convention de nommage des flots, le flot defini dans le fichier /WEB-INF/flows/todolist- 
flow.xml peut etre demarre a l'adresse suivante : 

http://localhost:8080/tudu-springwebflow/flow/todolist-flow.htm 
En resume 

Nous avons vu dans cette section la configuration minimale du moteur de Spring Web Flow 
afin de faire executer un flot Web tres simple. Cependant, Spring Web Flow n'est generale- 
ment pas utilise seul dans une application Web et doit cohabiter avec un framework Web. 
Nous avons done vu sa configuration au sein d'une application Spring MVC. 

Spring MVC et Spring Web Flow etant chacun tres souple, nous avons vu un mode de cohabi- 
tation possible, mais il en existe bien d'autres (vues de type Velocity ou FreeMarker, integration 
de vues composites avec Tiles, etc.). 



Langage d'expression et portees 

Spring Web Flow propose un langage de programmation specialise sous forme XML pour 
definir les flots. Ce langage, volontairement simple et non generaliste, est done limite pour 
exprimer certaines notions. C'est pour cette raison que la valeur de certains attributs dans la 
definition XML d'un flot peut contenir des instructions dans un langage d'expressions, ou EL 
(Expression Langage). 

Lutilisation d'un tel langage permet aux definitions de flot d'etre beaucoup plus puissantes, 
tout en gardant le langage de definition tres simple. Les instructions sont notamment utilisees 
pour des appels de methodes sur des Beans Spring, des verifications, etc. 

Voici un exemple d'instruction : 

<decision-state id="checkResul tSize"> 
<if test="flowScope.todol_ists.size( ) = 1" 

then="extractResul t" else="show.todolists" /> 
</decision-state> 

Linstruction flowScope.todol_ists.size( ) == 1 est interpretee dynamiquement par Spring 
Web Flow lors de F execution du flot, en fonction de son contexte. Voici l'equivalent Java de 
cette expression : 

((Collection) f 1 owScope.get( "todoLi sts" ) ) . size( ) == 1 

Cette instruction verifie la taille d'une liste de TodoLi st dans le contexte d'un flot. Elle permet 
revaluation d'une condition afin d'effectuer un routage dans le flot, car elle est faite au sein 
d'un etat d'aiguillage (decision-state). 

Dans quel langage est cette expression ? Nous avons parle d'un langage d'expression, mais 
cette notion est plutot vague. L'utilite du langage d'expression est sa simplicite pour acceder 
aux proprietes d'un objet ou pour appeler des methodes. Nous avons vu cette simplicite avec 
l'equivalent Java de notre exemple d'instruction, qui se trouve etre plus complexe (trans- 
typage necessaire, utilisation d'une methode get, etc.). Le langage d'expression s'apparente 
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done a un langage de script, avec une syntaxe plus souple et permissive que du Java. Chaque 
langage a son avantage, mais un langage d' expression est particulierement adapte a une utili- 
sation au sein de definitions de flots. 

Spring Web Flow supporte deux implementations de langages d' expression. La premiere est 
le Java Unified EL, qui fait partie de la specification JSP 2.1. JBoss EL est une implementa- 
tion de ce standard. Spring Web Flow utilise Java Unified EL par defaut. 

Lautre implementation supportee est OGNL (Object Graph Navigation Language). OGNL 
est utilise notamment par des projets comme Struts 2, Tapestry 4 et Apache Camel. 

Les deux implementations (Java Unified EL et OGNL) sont relativement equivalentes pour les 
besoins que nous rencontrons dans des flots Web. Etant donne que Spring Web Flow se confi- 
gure en fonction de ce qu'il trouve dans le classpath, il n'y a pas de configuration specifique a 
faire. Nous utilisons OGNL pour l'ensemble des exemples d' expressions de ce chapitre. 

Variables implicites 

Spring Web Flow definit un ensemble de variables implicites qui sont accessibles depuis un 
flot. Le tableau 8-1 recense l'ensemble de ces variables implicites. 



Tableau 8-1 . Variables implicites accessibles via le langage d'expression 



Nom 


Description 


fl owScope 


Portee du flot, dont le cycle de vie est lie a une instance de flot (creation et fin du flot). 


viewScope 


Portee d'une vue, dont le cycle de vie est lie a une vue (entree et sortie de la balise 
view-state). 


requestScope 


Portee de requete, dont le cycle de vie est lie a une requete sur un flot (entree et sortie 
du flot). 


fl ashScope 


Portee creee a la creation d'un flot, videe apres qu'une vue est rendue et detruite a 
la fin du flot. 


conversationScope 


Portee d'un flot, dont le cycle de vie est lie a une instance de flot (creation et fin du 
flot), accessible par tous les flots fils. 


requestParameters 


Parametres de requetes du client (les parametres HTTP pour une application Web). 


currentEvent 


Permet d'acceder aux propriet.es de I'evenement courant. 


currentUser 


Permetd'accederal'utilisateurauthentifie, w'ason Principal. 


messageContext 


Acces au contexte de messages d'un flot (erreur et confirmation, etc.). 


resourceBundl e 


Acces a un MessageResource pour I'internationalisation. 


f 1 owRequestContext 


Acces au contexte de la requete courante du flot. 


f 1 owExecutionContext 


Acces au contexte d'execution du flot. 


external Context 


Acces a I'environnement externe au flot, par exemple la session HTTP. 



Chacune des variables correspond a une classe, dont les proprietes et methodes sont accessibles 
par le langage d'expression. 



Les frameworks de presentation 

Partie II 



L' enumeration de ces variables nous a permis d'introduire un concept important de Spring 
Web Flow : les portees. Spring Web Flow dispose de cinq types de portees, qui, comme la 
session HTTP pour une application Web, permettent de gerer un contexte (les differents objets 
stockes lors de l'execution du flot). Les portees les plus couramment utilisees sont la portee du 
flot (flowScope), la portee de la requete (requestScope) et la portee de la conversation 
(conversationScope), si Ton utilise des sous-flots. 

Les donnees stockees dans les portees flot, vue, flash et conversation doivent etre serialisables, 
c'est-a-dire que les instances d'objets stockees doivent etre d'une classe implementant 
Serializable. En effet, Spring Web Flow utilisant la session HTTP pour gerer ces portees, 
tous les objets stockes sont susceptibles d'etre serialises en cas de replication de sessions 
(dans un environnement en cluster). 

Quand on souhaite acceder a une variable contenue dans une portee, on precise generalement 
la portee. II est cependant possible d'omettre la portee. Spring Web Flow tente en ce cas de 
resoudre la valeur en cherchant successivement dans les portees suivantes : request, flash, 
view, flow et conversation. 

Voici un exemple d'acces a une variable dans la portee flot : 

<deci si on -state id="checkResul tSize"> 

<if test="flowScope.todoLists .size( ) == 1" 

then="extractResul t" el se="show.todol i sts" /> 
</decision-state> 

Les variables implicites sont accessibles depuis les fichiers de configuration, mais aussi 
depuis les vues, par exemple pour une vue JSP utilisant JSTL : 

<p><a href="${flowExecutionUrl }&_eventId=end">Back to home</a></p> 



Configuration des elements d'un flot 

Comme indique precedemment, un flot est constitue d'un ensemble d'etats, qui peuvent 
s'enchainer grace a des transitions. Nous avons vu que Spring Web Flow propose differents 
types d'etats (action, vue, aiguillage, etc.). Le panel de fonctionnalites de Spring Web Flow ne 
s'arrete pas la, notamment avec les notions d'evaluation et de synchronisation d'une vue avec 
un modele. 

Un premier exemple de flot nous a montre les bases de Spring Web Flow. Nous allons voir 
comment ces differents elements peuvent etre configures, afin d'elaborer des flots plus 
complexes. 

Evaluation 

La notion d'evaluation correspond a revaluation d'une expression. Cette expression corres- 
pond a l'appel d'une methode sur un objet, qui peut etre un Bean Spring (par exemple, pour 
un appel metier) ou un objet contenu dans une des portees. 

Voici un exemple d' appel sur un service metier pour persister un objet recupere d'une vue 
(todoListEdit) : 
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<eval uate 



expression="todoLi stsManager . updateTodoLi st(todoLi stEdi t) " /> 

Souvent, revaluation retourne une valeur qui doit etre exploitee dans le flot. Voici un exemple 
recuperant la liste des TodoLi sts de Futilisateur courant et qui la stocke dans la portee du flot, 
sous la cle todoLists : 

<eval uate express i on="userManager . getCurrentllser( ) . getTodoLi sts( ) " 
resul t="f 1 owScope . todoLi sts" /> 

Les evaluations peuvent etre utilisees a differents endroits d'un flot. Le cas le plus courant est 
au sein d'un etat d' action : 

<acti on-state id="todol i sts"> 
<eval uate 

expression="userManager.getCurrentllser( ) .getTodoLists( )" 
resul t="flowScope. todoLi sts" /> 

transition on="success" to="checkResul tSi ze" /> 
</action-state> 

On peut aussi executer une evaluation juste avant le rendu d'une vue afin, par exemple, de 
charger des donnees dans la portee de la vue : 

<view-state id="show.todolist" view="todolist"> 
<on- render> 

<evaluate expression="todol_istAction.setupForm" /> 
</on-render> 
(...) 

</view-state> 

Globalement, les evaluations reagissent a un evenement dans le flot : depart d'un flot, entree 
et sortie d'un etat, fin d'un flot. Le schema XML permet de savoir facilement oil une evalua- 
tion peut etre positionnee. 

Grace au langage d' expression, les evaluations sont a la fois simples et puissantes. Elles 
permettent notamment d'effectuer des appels de methodes arbitrages sur des objets. Ces 
objets n'ont aucune interface specifique a implemented le branchement entre un flot et tout 
objet Java pouvant se faire sans couche d'interfacage. 

Transition 

La notion de transition permet le passage d'un etat a un autre. Une transition est provoquee 
par un evenement, typiquement la soumission d'un formulaire dans une vue. Les etats disposent 
done tous d'au moins une transition, mais elles en ont generalement plusieurs. 

La definition d'une transition est relativement simple : elle contient l'etat a atteindre (attribut 
to) apres le declenchement d'un evenement (attribut on) : 

transition on="success" to="show.todolist" /> 



II est possible d'effectuer une evaluation lors d'une transition. Selon le resultat (booleen) de 
cette evaluation, la transition prend effet ou pas. 
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Voici une evaluation au sein d'une transition : 

transition on-"submit" to="todoAdded" > 

<evaluate expression="todoAction.addTodo(todo)" /> 
</transition> 

La methode addTodo renvoie true ou fal se selon que Ton doit passer a l'etat suivant ou rester 
au meme : 

public class TodoAction { 
(...) 

public boolean addTodotTodo todo) { 
try { 

service. addTodo(todo) ; 
return true; 
} catch (TooManyTodoException e) { 
return false; 

} 

} 

Dans le cas ou une evaluation est presente, Fattribut to d'une transition n'est pas obligatoire. 
II correspond au cas ou la transition n'est utilisee que pour reagir a un evenement et lancer un 
traitement (via une ou plusieurs evaluations). Le flot reste alors au meme etat. Ce cas parti- 
culier n'est generalement utile que dans les etats d'affichage de vue. 

Si l'une des actions utilise exactement les memes transitions (meme identifiant d'evenement 
et meme etat cible), il est possible d'utiliser des transitions globales, avec la balise global - 
transitions : 

<global -transitions> 

transition on="success" to="todos" /> 
</global -transitions) 

Des lors qu'une transition n'est pas disponible dans un etat, les transitions globales sont eligibles 
pour indiquer au moteur de flot vers quel etat le flot doit poursuivre. 

Etats d'action 

L'etat d'action correspond a l'execution d'une methode d'un objet Java. L'objet Java est gene- 
ralement un Bean Spring, soit un service metier, soit une action. Si la notion de service metier 
est claire, la notion d'action dans Spring Web Flow merite une explication. 

Une action se rapproche d'un controleur au sens de Spring MVC, mais a une granularite plus 
fine. Quand un controleur retourne une valeur, celle-ci influe directement sur la vue qui est 
affichee ensuite. 

Le code retour d'une action influe plutot sur le flot Web, en indiquant, par exemple, vers quel 
etat se diriger, etat qui n'est pas forcement une vue. Dans les deux cas (controleur et action), 
un ou plusieurs appels metier sont generalement effectues. 

Dans la plupart des cas, une action est un singleton et est susceptible d'etre accedee de facon 
concurrente. Elle doit done etre threadsafe. Pour cela, tout comme un controleur, elle ne doit 



Spring Web Flow 

Chapitre 8 



pas avoir d'etat interne (aucune propriete) ou, si elle en a, ils ne doivent etre accedes qu'en 
lecture seule. Pour eviter tout probleme de concurrence dans une action, il suffit de ne lui 
injecter que des services eux-memes threadsafe. 

Dans Spring Web Flow, un etat d'action est declare avec la balise action-state. L'action 
effectuee est elaboree avec une ou plusieurs evaluations : 

<acti on-state id="todol i sts"> 
<eval uate 

expression="userManager.getCurrentUser( ) .getTodoLists( )" 
resul t="f 1 owScope.todoLi sts" /> 
<transition on="success" to="checkResul tSi ze" /> 
</action-state> 

Une fois comprise la notion d'evaluation, celle d'etat d'action est tres simple. II existe cepen- 
dant une subtilite, qui reside entre le resultat de revaluation et la transition. 

Une evaluation pouvant etre effectuee sur du code arbitraire (ne devant pas respecter une 
certaine API), la valeur de retour de l'expression est tout aussi arbitraire. Or c'est cette valeur 
que Spring Web Flow utilise pour choisir la transition a declencher. 

Spring Web Flow definit trois transitions implicites (attribut on de transition) : yes (valeur de 
retour true), no (valeur de retour false) et success (toute valeur de retour, sauf pour les 
enumerations). Si une methode retourne une enumeration, c'est le nom de l'enumeration qui 
est utilise pour choisir la transition. 

Le tableau 8-2 resume les choix de transitions en fonction de la valeur de retour d'une evaluation. 



Tableau 8-2. Correspondances entre valeurs de retour et transition 



Type de retour 


Identifiant de transition 




Booleen 


yes pour true et no pour f al se. 




Enumeration 


Nom de l'enumeration. 




Chafne de caracteres 


Valeur de la chaine de caracteres. 




Tout le reste 


Success. 






Si, par exemple, un Bean stati sti cs renvoie un booleen indiquant si un utilisateur a suffisam- 
ment de Todos, nous pouvons exploiter le resultat de la maniere suivante : 

<acti on -state id="addMoreTodo"> 

<evaluate expression="statistics.enoughTodo()" /> 

transition on="yes" to="todoSummary" /> 

transition on="no" to="addTodo" /> 
</action-state> 

Pour des prises de decision simples, il est preferable d'utiliser un etat de decision, qui propose 
une syntaxe plus simple. 
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Etat de decision 

Spring Web Flow propose une syntaxe bien adaptee a la prise de decision dans un flot. 

Voici comment prendre une decision selon le nombre de Todos recuperes pour l'utilisateur 
courant : 

<deci si on -state id="checkResul tSize"> 

<if test="flowScope. todos. sizeO == 1"<— Q 

then="extractResul t"<— Q 

else="show. todos" /><— Q 
</decision-state> 

L'attribut test permet d'effectuer la verification, en respectant la syntaxe du langage 
d'expression (Q). II faut que cette expression retourne une valeur booleenne. L'attribut then 
indique l'etat vers lequel se diriger si le resultat du test est evalue a true, et l'attribut else 
l'etat vers lequel se diriger si le resultat est evalue a f al se. 

La syntaxe concise et expressive de l'etat de decision est une solution de rechange a un etat 
d'action effectuant une evaluation simple. 

Etats de vue 

Les etats de vue permettent a un not d'interagir avec l'utilisateur. Quand un flot arrive dans un 
etat de vue, il est momentanement suspendu, jusqu'a ce qu'un evenement (lien ou soumission 
de formulaire) provoque la transition vers l'etat suivant. 

Les etats sont un des sujets les plus complexes de Spring Web Flow, car il est necessaire de 
prevoir toutes les actions possibles de l'utilisateur tout en gardant a l'esprit l'ergonomie. 

Nous allons voir dans cette section des mecanismes essentiels aux etats de vue (resolution des 
vues, chargement de donnees initiales, provocation d'un evenement pour changer d'etat). 

Nous verrons ensuite comment agrementer les vues avec la gestion des messages de Spring 
Web Flow. Nous verrons enfin deux moyens differents de gerer les formulaires d'un flot. 

Definition et resolution des vues 

Un etat de vue est defini par la balise view-state, qui comprend obligatoirement l'attribut id 
pour identifier l'etat et optionnellement l'attribut vi ew afin de preciser le nom de la vue pour le 
rendu. Dans la configuration minimale, Spring Web Flow deduit la vue a utiliser par rapport a 
l'identifiant de la vue. 

Par exemple, la definition suivante : 

<view-state id="welcome"> 

fait reference au fichier WEB-INF/flows/welcome.jsp si le fichier de definition du flot se 
trouve dans le repertoire WEB-INF/flows/. 

L'attribut view peut soit faire reference directement a un fichier, soit seulement identifier la 
vue. II s'agit dans ce dernier cas d'une information permettant a Spring Web Flow de resoudre 
la vue a utiliser. 
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Nous avons vu comment integrer le systeme de resolution de vue de Spring MVC avec celui 
de Spring Web Flow. Un etat de vue peut alors etre deflni de la facon suivante : 

<view-state id="show.todos" view="todos" > 

La valeur de Fattribut view est directement utilisee par le ViewResol ver de Spring MVC. 
Spring Web Flow est capable de s'integrer nativement avec Spring MVC (comme nous 
l'avons vu) et avec JSF, via le JsfViewFactoryCreator. 

Charger les donnees d'une vue 

Un flot contient generalement un ou plusieurs objets dont la duree de vie est directement liee 
a celle du flot. L'exemple typique est une reservation qui est renseignee sur plusieurs ecrans 
avant d'etre finalement persistee en base de donnees. Cependant, chaque vue doit contenir des 
donnees specifiques, par exemple des valeurs de references affichees dans des listes deroulantes. 

Avec Spring Web Flow, il est possible de charger ce genre de donnees juste avant qu'une vue 
ne soit affichee, en reagissant a l'evenement on - render : 

<view-state id-"show.todolist" view="todolist"> 
<on-render> 

<evaluate expression="todol_istAction.setupForm" /> 
</on-render> 

(...) 

</view-state> 

La methode executee peut soit mettre directement les donnees dans une des portees (flot, vue, 
etc.), comme dans notre exemple, soit utiliser Fattribut resul t de eval uate pour que le resultat 
soit stocke. Cette seconde possibilite permet d'utiliser des objets qui n'ont aucune connais- 
sance de Spring Web Flow, par exemple des services metiers. Dans les deux cas, les donnees 
sont ensuite accessibles depuis la vue pour etre affichees. 

Provoquer un evenement dans un etat de vue 

Le declenchement d'un evenement dans un etat de vue permet de provoquer une transition et 
done de faire evoluer le flot vers un etat suivant. 

Un evenement peut etre un lien, par exemple : 

<a href="${f 1 owExecutionUrl }&_eventId=todol i sts"> 

Back to Todo Lists 
</a> 

Le lien genere est le suivant : 

/tudu-springwebf 1 ow/f 1 ow/todol i st-f 1 ow. htm?execution=els2& 
_eventId=todol ists 

A travers le lien, Spring Web Flow doit pouvoir retrouver le flot. C'est le but de la variable 
implicite fl owExecutionUrl, appelee via le langage d'expression de JSTL. II faut aussi passer 
le nom de la transition (attribut to de transi ti on) avec le parametre HTTP _eventld. 
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Le declenchement d'un evenement peut aussi se faire par la soumission d'un formulaire. 
II faut alors, d'une part, que le formulaire appelle l'URL du Hot (attribut action de la balise 
form) afin que Spring Web Flow sache de quel Hot il s'agit. D'autre part, le bouton de soumission 
doit contenir le nom de la transition. 

Voici un exemple de formulaire qui sera gere par Spring Web Flow a sa soumission : 

<form action="${flowExecutionllrl }" method="post"> 
(...) 

<input type="submit" name="_eventld_save" value="Save" /> 
</form> 

Le nom du bouton de soumission doit respecter le motif _eventId_${nomTransition). 

Gestion de messages 

Spring Web Flow maintient un contexte de messages, qui permet d'afficher des messages 
d'erreur ou d'information a Futilisateur. 

Le contexte de message correspond a la variable implicite messageContext ; il peut done etre 
utilise a tout moment dans une definition de flot. Le contexte de message correspond a Finterface 
MessageContext. Cette interface permet d'ajouter un message avec la methode addMessage. 

Afin de faciliter la construction de messages, Spring Web Flow propose un MessageBuilder, 
qui a une API dite courante, e'est-a-dire qui permet d'enchainer les appels de methodes. 

Voici un exemple de son utilisation : 

MessageBuilder builder = new MessageBui 1 der( ) ; 
messageContext.addMessage(builder.info( ) 
.sourceC'todolist") 

.defaultText( "Todo List updated" ) .build( ) 

); 

Le message est informatif (methode info), en rapport avec une TodoList (methode source). 
Son libelle est assigne avec def aul tText. Le message est cree avec la methode build et assigne 
au MessageContext. 

II est possible d'internationaliser les messages, e'est-a-dire d'externaliser les libelles dans un 
ensemble de fichiers proprietes (un par langue) et de les referencer via un code. Pour cela, il 
suffit de declarer un MessageSource, par exemple : 

<bean id="messageSource" class=" 
org. springframework. context .support . ResourceBundl eMessageSource"> 
<property name="basename" val ue="tudu. web. Messages" /> 
</bean> 

La propriete basename fait reference a un fichier /tudu/web/Messages.properties, qui doit se 
trouver dans le classpath. Voici une partie de son contenu : 

todolist.updated=Todo List updated, 
todo . updated=Todo updated. 



Spring Web Flow 

Chapitre 8 



Spring Web Flow detecte la presence d'un MessageSource et configure le MessageContext arm 
qu'il soit a meme de resoudre les codes des messages. 

Voici comment internationaliser un message (avec la methode code) : 

messageContext .addMessage(bui 1 der . info( ) 
. source( "todol 1 st" ) 
. code( "todol i st . updated" ) 
.defaultTextC'Todo List updated" ) .bui 1 d( ) 

); 

Dans la vue, les messages peuvent etre affiches en recuperant le MessageContext a partir du 
contexte du flot et en appelant la methode getAl 1 Messages via une balise JSTL : 

<c:forEach 

i tems="${f 1 owRequestContext .messageContext . al 1 Messages} " 
var="message"> 
<p>$ {mess age. text }</p> 
</c:forEach> 

Les messages permettent d'informer l'utilisateur sur ses actions, aussi bien pour des erreurs 
de validation que pour des confirmations. Le contexte de message etant une variable implicite, 
il est possible de le passer a des methodes de Bean dans une definition de flot, arm d'enregistrer 
des messages de facon programmatique. 

Linternalisation des messages est tres aisee, se fondant sur le principe de MessageSource de 
Spring, et done de Spring MVC. 

Gestion et validation d'un modele 

Spring Web Flow propose un support pour lier des objets de domaine avec une vue. Ce 
support est principalement utilise pour l'edition d' objets via des formulaires. II est aussi possi- 
ble d'effectuer une validation apres qu'un objet de domaine a ete mis a jour avec les champs 
d'un formulaire. 

Voici comment lier une vue a un objet de domaine : 

<view-state id="updateTodo" model="todo" > 

L' objet todo est issu d'une des portees du flot, recuperee selon 1'algorithme de resolution des 
portees. La valeur de l'attribut model est importante non seulement pour retrouver le bon objet, 
mais aussi parce que Spring Web Flow va referencer le modele de la vue avec cette valeur. 

Dans notre exemple, il s'agit de todo. Nous aurions pu utiliser aussi f 1 owScope . todo pour refe- 
rencer completement notre modele ; il aurait alors pris ce nom. Nous referencerons par la 
suite ce nom avec l'expression $ {model }. 

Specifier un modele pour une vue provoque : 

• un lien vue-modele lors de la soumission d'un formulaire (les parametres HTTP sont 
injectes dans le modele) ; 

• une potentielle validation. 
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Si les transitions d'un etat de vue sont soumises a un lien vue-modele et a une validation, il faut que 
les deux se deroulent correctement pour que la transition puisse amener le flot a l'etat suivant. 

Prenons, par exemple, la mise a jour d'un Todo. II est dans un premier temps charge par un etat 
d'action pour etre affiche dans une vue. 

Voici la configuration du not : 

<action-state id="loadTodo"> 
<eval uate 

express i on-" todosManager .findTodo(flowScope. id)" 
result="flowScope.todo" /> 
<transition on="success" to="updateTodo" /> 
</action-state> 

<view-state id="updateTodo" model="todo"> 
transition on-"submit" to="showTodo" /> 
</view-state> 

La vue peut afficher un formulaire avec des proprietes du Todo : 

<form action="${flowExecutionllrl }" method="post"> 
Description : <input type="text" name="description" 

val ue="${todo. description}" /> <br /> 
Notes : <input type="text" name="notes" 

val ue="${todo. notes}" /> <br /> 
<input type="submit" name="_eventld_submit" val ue-"Submit"/> <br /> 
</form> 

Les proprietes du Todo peuvent etre affichees (via la syntaxe ${todo. description}) grace a 
Fexposition du Todo dans la portee flot et pas grace a Futilisation de l'attribut model . En revan- 
che, a la soumission du formulaire, les champs du formulaire vont etre lies au Todo du flot 
grace a Futilisation de model . 

II est possible de desactiver la synchronisation vue-modele pour une transition : 

transition on="cancel" to="show-todo" bind="false" /> 

Cela permet de disposer d'un bouton d'annulation dans le formulaire et de ne pas se retrouver 
bloque si une erreur de conversion a lieu : 

<input type="submit" name="_eventld_cancel " val ue="Cancel " /> 

Nous avons vu que la synchronisation est pilotee par les parametres HTTP qui sont envoyes. 
II est possible de limiter cette synchronisation en precisant explicitement les proprietes et 
done les parametres HTTP a prendre en compte : 

<view-state id="updateTodo" model="todo"> 
<binder> 

<binding property="description" /> 
<binding property="dueDate" /> 
</binder> 

<transition on="submit" to="showTodo" /> 
</view-state> 
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II est encore possible d'affiner la conversion en precisant que la propriete est obligatoire (attribut 
requi red) et en positionnant un convertisseur a utiliser pour la propriete : 

<binder> 

<binding property="description" /> 

<bi ndi ng property="dueDate" converter="date" requi red="true" /> 
</binder> 

L' attribut converter permet de preciser le convertisseur, c'est-a-dire l'objet qui se charge de 
transformer le parametre HTTP en la propriete de l'objet. 

Spring Web Flow effectue les conversions des parametres HTTP vers les proprietes d'un objet 
Java (ainsi que 1' inverse, qui correspond a une notion de formatage) avec un ensemble de 
convertisseurs. 

Par defaut, un DefaultConversionService est positionne pour s'acquitter des taches de conver- 
sion, qu'il delegue a un ensemble de convertisseurs (il y a generalement un convertisseur pour 
chaque classe a convertir). Pour effectuer des conversions complexes ou preciser certains 
formats (par exemple, pour les dates), il devient necessaire de positionner son propre 
ConversionService. 

Voici un exemple d'implementation, utilisant des classes fournies par Spring Web Flow 
(GenericConversionService, StringToDate et StringToBoolean) : 

public class TuduListsConversionService 
extends GenericConversionService { 

public Tudul_istsConversionService( ) { 
addDef aul tConverters( ) ; 
addDef aul tAl i ases( ) ; 

} 

protected void addDefaultConverters( ) { 

StringToDate dateConverter = new StringToDate( ) ; 
dateConverter . set Pattern ( "MM/dd/yyyy" ) ; 
addConverter(dateConverter) ; 
addConverter( "date" , dateConverter) ; 
addConverter(new StringToBool ean( ) ) ; 

} 

protected void addDef aul tAl i ases( ) { 
addAl i as( "date" , Date. class); 
addAl ias( "bool ean" , Bool ean .cl ass ) ; 

} 

} 

Dans cet exemple, nous positionnons deux convertisseurs, un pour les dates (pour lequel nous 
precisons un format) et un pour les booleens. Cet exemple est volontairement simple, pour des 
problematiques d'espace, mais nous vous enjoignons a consulter le code source et la docu- 
mentation Java de DefaultConversionService pour positionner des convertisseurs pour les 
types les plus courants. 
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II est ensuite necessaire de positionner notre convertisseur dans la configuration de Spring 
Web Flow : 

<webf 1 ow: f 1 ow- regi stry i d="f 1 owRegi stry " 

f low-bui lder-servi ces="f 1 owBui 1 derServices"><— Q 
<webf 1 ow:f 1 ow-1 oca t ion -pattern 

value="/WEB-INF/flows/**/*-flow.xml" /> 
</webf 1 ow: f 1 ow- regis try > 

<webf 1 ow:f 1 ow-bui 1 der- services id="f 1 owBui 1 derServices"<— Q 
conversion-servi ce=" con vers ionService"<—@ 
expression-parser="expressi on Parser" /><— Q 

<bean id="conversionService" class="<— Q 
tudu. web. samples . views t ate. binding.TuduListsCon vers ionService" /> 

<bean id="expressionParser" class="<— Q 

org.springf ramework.webf low. express ion. Web FlowOgnl Express ion Parser" 

> 

<property name="conversionService" ref="conversionService" /> 
</bean> 

Nous definissons au repere © notre ConversionService, qui est aussi utilise par le parseur 
d'expressions (©). Ces deux services sont ensuite positionnes (© et ©) sur le Bean regrou- 
pant les differents services internes de Spring Web Flow (©), lui-meme utilise par le registre 
de flots (©). 

Avec cette configuration, notre service de conversion peut etre utilise aussi bien lors d'une 
synchronisation complete (utilisation simple de l'attribut model) que lors des conversions 
explicites (attribut converter de binding). 

Quand, precedemment, nous avons precise le convertisseur a utiliser : 
<binding property="dueDate" converter="date" requi red="true" /> 

le nom date faisait reference a la ligne suivante dans notre service de conversion : 

addConverter( "date" , dateConverter) ; 

Une fois la synchronisation du modele effectuee, Spring Web Flow est capable d'effectuer une 
validation sur le modele. Cette validation est purement programmatique, car Spring Web Flow 
ne propose pas de mecanisme declaratif, de type Struts Validator. 

Spring Web Flow propose deux moyens de valider un modele : soit disposer de methodes de 
validation directement dans la classe du modele, soit declarer un Bean de validation pour un 
modele. Nous allons voir chacune des methodes. 

Le modele peut comporter directement des methodes de validation. Pour cela, Spring Web 
Flow n'impose aucune interface a implementer. Le modele doit simplement contenir des 
methodes de la forme val idate${etat}, ou ${etat} est le nom de l'etat. Ces methodes doivent 
aussi accepter un parametre de type MessageContext afin d'enregistrer des messages d'erreur. 
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Voici l'exemple d'une methode de validation dans un Todo : 



(...) 

import org. springf ramework. binding. message. Mess ageBuilder; 

import org. springf ramework. binding. message. Mess ageContext; 

import org. springframework. util .StringLltils; 



public class Todo implements Serializable { 



(...) 



public void val idateLlpdateTodo(MessageContext messageContext) { 
if ( ! StringUti 1 s . hasTextt description) ) { 
messageContext. addMessage(new MessageBui 1 der( ) . 
error( ) . source ( "description" ) . 
defaultText("Description is requi red" ) . bui 1 d( ) ) ; 



Notre etat de vue s'appelant updateTodo, il faut que la methode s'appelle val idateUpdateTodo 
afin que Spring Web Flow puisse la detecter et Fappeler. La validation effectuee dans le 
modele a des avantages et des inconvenients. Elle permet une bonne reutilisabilite de la vali- 
dation, puisqu'elle se trouve dans l'objet de domaine. II s'agit d'un bon point de depart pour 
un modele de domaine riche. En revanche, elle presente un cote intrusif, du fait d'une depen- 
dance directe envers F API de Spring Web Flow et les conventions de nommage. 

L'utilisation d'un validateur dedie est la deuxieme solution proposee par Spring Web Flow. Le 
validateur est un objet separe du modele, qui doit declarer des methodes de type 
val idate${etat}, ou ${etat} est le nom de l'etat a valider. Ces methodes doivent accepter en 
parametres une instance du modele et un MessageContext. Le validateur doit etre enregistre 
dans le contexte Spring sous le nom $ {model } Val idator. 

Voici un exemple de validateur sur lequel a ete apposee une annotation ©Component, utilisee 
pour la detection automatique de composant : 

(...) 

import org. springf ramework. binding. message. Mess ageBuilder; 
import org. springf ramework. binding. message. MessageContext; 
import org. springf ramework. stereotype .Component ; 
import org. springframework. util . StringLltils; 

import tudu. domain. model .Todo; 

©Component 

public class TodoVal idator { 



public void val idateLlpdateTodo( 

Todo todo. MessageContext messageContext) { 
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i f ( ! StringUti 1 s . hasText(todo.getDescri ption( ) ) ) { 
messageContext.addMessage(new MessageBui 1 der( ) . 
error ( ) . source ( "description" ) . 
defaultTextC'Description is requi red" ) .bui 1 d( ) ) ; 

} 

} 

} 

Avec la convention de nommage de l'annotation ©Component, le validateur a pour nom 
todoVal idator dans le contexte Spring, ce qui permettra de valider le modele todo. La 
methode val idateUpdateTodo sera appelee pour l'etat updateTodo. 

Pour resumer, Spring Web Flow propose un support natif pour synchroniser une vue et un 
modele, ainsi que pour valider ce modele. II est possible de parameter finement la synchroni- 
sation avec ConversionService. La validation proposee par Spring Web Flow est programma- 
tique. Elle peut se trouver directement dans le modele ou dans un validateur dedie. 

Gestion d'un formulaire avec FormAction 

FormAction est une solution de rechange au systeme de synchronisation et de validation natif 
de Spring Web Flow. L'utilisation combinee d'une FormAction et d'elements de Spring MVC 
(synchronisation, bibliotheque de balises) facilite grandement la gestion de la plupart des 
formul aires. 

Voici les etapes typiques de gestion d'un formulaire : 

1. Entree dans un etat de vue. 

2. Preparation des donnees de la vue. 

3. Soumission du formulaire par l'utilisateur. 

4. Synchronisation des champs du formulaire avec un modele. 

5. Validation du modele. 

6. Si la synchronisation et la validation se deroulent correctement, appels metier et 
passage a l'etat suivant. Dans le cas contraire, retour a la vue. 

Dans ces etapes, une FormActi on gere la plupart des mecaniques internes, laissant des branche- 
ments disponibles pour le code applicatif. 

Pour la gestion d'un formulaire, on cree une classe heritant de FormAction : 
package tudu.web; 

import org.springf ramework.webf 1 ow. action. FormAction; 
public class TodoListAction extends FormAction { 



(...) 

} 
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Le tableau 8-3 recense les methodes de FormAction les plus frequemment surchargees pour 
s'adapter aux besoins d'un formulaire. 



Tableau 8-3. Methodes de FormAction a surcharger 



Methode 


Description 


create FormObject( Request Context) 


Creation du modele a utiliser pour le formulaire. A surcharger si 
I'objet doit etre recupere depuis la base de donnees ou si sa crea- 
tion est specifique. Par defaut, une instance de la classe retournee 
par getFormObjectCl ass est creee. 


validationEnabl ed(RequestContext ) 


Permet de decider dynamiquement si la validation doit avoir lieu. 
Retourne true par defaut. 


Le tableau 8-4 recense les methodes qui sont appelees pendant le cycle de vie de l'etat de vue. 
L'appel de ces methodes est a parameter dans la configuration XML du flot. 


Tableau 8-4. Methodes de FormAction a appeler 


Methode 


Description 


set upForm( RequestContext ) 


Preparation du modele a utiliser par le formulaire. Appelle notam- 
ment createFormObject pour la creation du modele. Le modele 
est positionne dans la portee parametree pour la FormAction. 


bindAndVal i date ( Reques tContext) 


Synchronisation des champs du formulaire avec le modele puis Ian- 
cement de la validation avec le validateur positionne. 


bind (RequestContext) 


Synchronisation des champs du formulaire avec le modele. Aucune 
validation n'est lancee. 


validate (RequestContext) 


Validation du modele. 


Une FormActi on contient un ensemble de proprietes qu'il est possible d'assigner pour parame- 
ter finement la gestion de l'etat de vue et le formulaire. Le tableau 8-5 liste certaines de ces 
proprietes. 


Tableau 8-5. Proprietes de FormAction 


Propriete Valeur par defaut 


Description 


formObjectName formObject 


Norn du modele. Ce nom sera utilise comme cle pour stacker 
I'objet dans la portee parametree. 


formObjectCl ass null 


Classe du modele. 


formObjectScope ScopeType. FLOW 


Portee dans laquelle le modele est stocke. Dans la portee de 
flot, le modele est mis en cache et stocke pour toute la duree 
du flot. 


validator null 


Le validateur du modele. 

1 
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Nous avons recense ici les principales caracteristiques d'une FormAction. La documentation 
API de FormAction contient une liste exhaustive de ses methodes et proprietes. N'hesitez done 
pas a la consulter pour des besoins plus precis. 

Une fois tous ces elements en tete, nous allons voir les differents elements a implementer en 
prenant pour exemple un etat utilisant une classe fille de FormAction. 

Voici la definition du not : 

<view-state id="show.todol ist" view="todol ist"> 
<on-render> 

<evaluate expression="todoListAction.setupForm" /><— Q 
</on-render> 

<transition on="save" to="todolists"> 

<evaluate expression="todoListAction.bindAndValidate" /><— Q 

<evaluate expression-" 

todoLi stsManager .updateTodoLi st(todoLi stEdi t)" /><— Q 
</transition> 

transition on-"todos" to="todos" /> 
<transition on="todol i sts" to="todol ists" /> 
</view-state> 

Lors du rendu de la vue, la methode setupForm est appelee afin de charger les donnees neces- 
saires au formulaire. Lors de la soumission du formulaire, les champs sont synchronises avec 
le modele, puis une validation a lieu. Ces deux actions sont effectuees grace a la methode 
bindAndVal idate (Qi). Si la validation et la synchronisation reussissent, une methode metier 
est appelee pour persister le modele (©). 

La FormAction est un Bean Spring qui peut etre declare explicitement ou via une detection 
automatique de composant (annotation ©Control 1 er). 

En voici un exemple d' implementation : 
©Control 1 er 

public class TodoListAction extends FormAction { 

public TodoLi stActi on ( ) { 

set FormOb j ect Name ( "todo List Edit" ) ;<— O 
setVal idator(new TodoListVal idator( ) ) ;<— © 
set FormOb jectScope(ScopeType. REQUEST) 

} 

protected Object createFormObject( RequestContext context) 
throws Exception { 
return context .get Fl owScope( ) .get( "todoLi st" ) ;<— Q 

} 

) 

Nous commen§ons par attribuer un nom a l'objet du formulaire, que nous appelons aussi le 
modele (Q). Un validateur est ensuite positionne (Q). Celui-ci pouiTait tout aussi bien avoir 
ete positionne de fa?on declarative, par injection de dependances. Nous avons opte pour un 
positionnement programmatique, qui est plus simple, mais plus rigide. 
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La portee de requete va etre utilisee pour stocker l'objet. Nous verrons dans l'etude de cas 
qu'au cours d'un meme flot plusieurs TodoLi sts peuvent passer dans cet etat de vue (en effet, 
on selectionne une TodoLi st a editer dans une liste). En utilisant la portee de requete, l'objet 
est recupere systematiquement, via la methode createFormObject, a partir de la portee de flot. 

Si nous laissions l'objet du formulaire dans la portee flot, il serait mis en cache et la methode 
createFormObject ne serait appelee qu'une fois. Nous ne pourrions des lors editer qu'une 
seule TodoLi st, celle qui aurait ete selectionnee en premier dans le flot ! 

Un validate ur est utilise pour valider notre modele. Voici son implementation : 
package tudu.val idation ; 

import org.springf ramework.val idation. Errors ; 
import org.spri ngf ramework.val i dati on. Validationlltils; 
import org.springf ramework.val idation.Val i da tor ; 
import tudu. domain. model .TodoList; 

public class TodoListVal idator implements Validator {<— O 

public boolean supports(Cl ass clazz) { 

return TodoList.class.isAssignableFrom(clazz) ;<— Q 

} 

public void val idatetObject target, Errors errors) { 
Val idationUti 1 s . reject If Empty OrWhites pace ( 

errors, "name", "todol ist. description. not. empty" 
);<-© 

} 

} 

Le validateur implemente l'interface Validator de Spring (Q). Cette interface declare une 
methode permettant de savoir si le validateur est capable de valider une classe (Q) et 
une methode effectuant la validation. Nous utilisons ici des methodes de validation de Spring 
(©)■ Spring Web Flow fait ensuite le lien avec son propre systeme de messages. 

La vue est implementee avec les balises de formulaire de Spring MVC, qui permettent notam- 
ment de lier les champs du formulaire avec l'objet de formulaire, aussi bien en ecriture qu'en 
lecture : 

<%@taglib prefix-"c" uri="http: //java . sun.com/jsp/jstl/core" %> 
<%@taglib pref ix="form" 

uri=" http://www.spr ingframework.org/tags/form" %> 

<form:form commandName="todoLi stEdit"><— © 
<form:errors path="*" /><— Q 
<table> 
<tr> 
<td>ID</td> 

<td><form:input path="l i stld" readonly="true"/X/td><— © 
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</tr> 
<tr> 
<td>Name</td> 

<td><form: input path="name" /></td><— Q 
</tr> 

<tr colspan="2"> 
<td> 

<input type="submit" name="_eventld_save" value="Save" /><— Q 
</td> 
</tr> 
</table> 
</form:form> 

La balise form: form permet de lier le formulaire avec le modele. Nous utilisons bien le nom 
defini dans Taction (Q). La balise form:errors (Q) affichera Fensemble des messages 
d'erreur (pour la synchronisation et la validation). Les deux proprietes a synchroniser sont 
declarees avec des balises form: i nput (Q et Q). Enfin, le bouton de soumission est configure 
de facon a lancer la transition save (©). 

En resume, la classe FormActi on permet de gerer tres facilement des formulaires au sein de nos 
Hots. Elle implemente la plupart des mecanismes recurrents, en laissant des ouvertures pour 
brancher du code applicatif et fonctionne d'une maniere tres proche de Spring MVC, notam- 
ment pour la gestion des vues. De cette maniere, il est possible de profiter de la puissance de 
Spring Web Flow pour gerer le contexte et la cinematique et de Spring MVC pour la gestion 
des vues. 

Sous-flot 

Les Hots Web etant par essence reutilisables, il est possible de les faire interagir les uns avec 
les autres. Un flot principal peut appeler des sous-dots et, dans ce cas, suspendre son execution le 
temps de l'execution du sous-flot. 

Spring Web Flow fournit un etat acet effet, defini parle biais de la balise subf low -state. Cette 
balise comprend un attribut id correspondant a Fidentifiant de l'etat (dans le flot courant), 
ainsi qu'un attribut subf 1 ow permettant de relier l'etat au flot a executer : 

| <subflow-state id="todos" subflow="todo-flow"> 

II est possible de passer des parametres du flot parent vers le sous-flot a Faide de la balise 
input : 

<subf 1 ow-state id="todos" subf 1 ow="todo-f 1 ow"> 
<input name="todol_i st" value="flowScope.todoList" /> 

<transition on="end" to="show.todolist" /> 
</subfl ow-state> 

Lattribut name correspond au nom du parametre tel qu'il est defini dans le sous-flot, et l'attri- 
but val ue a la valeur qui doit etre passee. Cette valeur fait bien sur reference a une variable se 
trouvant dan le flot courant. 

Tout not peut definir des parametres d'entree en recourant a la balise i nput au debut du flot. 
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Ainsi, le flot todo-flow (utilise en tant que sous-flot dans le flot todolist-flow) declare la 
TodoList qu'il attend de la facon suivante : 

<input name="todoList" value="flowScope.todol_ist" /> 

Nous retrouvons le nom de parametre (attribut name), qui vaut todoLi st. Ce parametre est mis 
dans la portee flot du sous-flot, avec la cle todoLi st. 

II faut preciser un etat dans lequel doit entrer le sous-flot pour que le not principal soit reactive. 
Cela se fait avec la balise transition dans sublow-state : 

<subfl ow-state id="todos" subf 1 ow="todo-f 1 ow"> 

<input name="todol_i st" value="flowScope.todoList"/> 

<transition on="end" to="show.todol ist" /> 
</subf 1 ow-state> 

Dans notre exemple, quand le sous-flot arrive a l'etat end, le flot principal est reactive et passe 
a l'etat show.todolist. Notons qu'il peut s'agir de n'importe quel etat du sous-flot, et non 
juste l'etat de fin. 

Securisation d'un flot 

Spring Web Flow propose une integration avec Spring Security pour securiser des Hots. Si 
notre application Web utilise Spring Security, nous pouvons securiser differents elements d'un 
not (le flot complet, un etat ou une transition) avec la balise secured. Nous n'allons voir que 
l'activation de Spring Security dans Spring Web Flow. Pour la configuration de Spring Security, 
voir le chapitre 14. 

Pour activer Spring Security dans Spring Web Flow, il est necessaire de brancher un ecouteur 
sur le cycle de vie des flots. Cela se fait dans la configuration de l'executeur de not : 

<webf 1 ow: f 1 ow- executor i d="f 1 owExecutor"> 
<webf 1 ow:f 1 ow-execution-1 i steners> 

<webf 1 ow: 1 i stener ref-"securityFlowExecutionl_istener" /> 
</webf 1 ow: fl ow-execution-1 i stener s> 

</webf 1 ow:f 1 ow-executor> 

<bean id="securi ty Fl owExecutionLi stener" 

cl ass="org. springf ramework.webf 1 ow. security . 
Securi tyFl owExecutionLi stener" /> 

Spring Web Flow propose de brancher des objets observant le cycle de vie des flots avec les 
balises flow-execution-listeners et listener. Nous declarons done 1' ecouteur Spring Security 
fourni, a savoir Securi tyFl owExecutionLi stener. 

II est possible de securiser la totalite d'un flot en limitant son acces aux utilisateurs ay ant le 
role ROLEJJSER : 

<flow (...)> 
<secured attributes-"ROLE_USER" /> 
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(...) 

</flow> 

La balise secured peut aussi etre apposee sur tout etat et toute transition, offrant ainsi une 
securisation de granularite tres fine. 

Securiser les flots sensibles est d'une importance capitale, car il ne suffit pas de dissimuler des 
liens pour restreindre des acces. L'interfacage de Spring Web Flow avec Spring Security 
permet une securisation tres simple pour toute application mettant en ceuvre Spring Security. 



Mise en oeuvre de Spring Web Flow dansTudu Lists 

Telle qu'elle est developpee, l'application Tudu Lists ne permet pas d'integrer facilement 
Spring Web Flow, car elle est notamment fondee sur la technologie AJAX. De plus, Tudu Lists 
ne propose pas vraiment de cas d'utilisation adapte a la gestion d'un flot. 

Nous allons done migrer les fonctionnalites de gestion des TodoLi sts et des Todos avec Spring 
Web Flow dans un sous-projet annexe et independant. Nous concevrons a cet effet deux flots 
gerant respectivement les TodoLi sts et les Todos. 

Nous allons tout d'abord decrire les deux flots Web, puis nous detaillerons des elements de 
F implementation de cette version Spring Web Flow de Tudu Lists. 

Conception des flots 

L'application se compose d'un flot principal, nomme todolist-flow, defini dans le fichier 
todolist-flow.xml, et d'un sous-Hot, todo-f 1 ow, decrit dans le fichier todo-flow.xml, tous deux 
dans le repertoire /src/main/webapp/WEB-INF/flows/. 

Le flot principal, todolist-flow, correspond a un flot Web d'affichage et de modification des 
TodoLi sts, comme l'illustre la figure 8-5. 



Figure 8-5 

Flot de gestion 
des TodoLists 
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La premiere etape consiste a charger les TodoLists de l'utilisateur courant. Un etat 
d'aiguillage, checkResultSize, analyse ensuite le nombre de TodoLists chargees. S'il y en a 
plus d'une, l'utilisateur est envoye vers une vue les affichant (show.todol ists). A partir de 
cette liste, l'utilisateur peut cliquer sur un lien pour voir le detail d'une TodoLi st (identifiant, 
nom). 

Si l'utilisateur n'a qu'une seule TodoLi st, un etat d'action l'extrait de sa structure de donnees 
(extractResul t) et dirige l'utilisateur vers le detail de cette unique TodoLi st. 

Le detail d'une TodoLi st permet de modifier ses caracteristiques et propose deux liens : un 
pour retourner a la liste des TodoLists, un autre pour voir la liste des Todos de cette TodoLi st. 

Voici la definition XML du not des TodoLists : 

<?xml version="1.0" encoding="UTF-8"?> 
<flow (...)> 

<secured attributes="ROLEJJSER" /> 

<action-state id="todol ists"> 
<eval uate 

expression="userManager.getCurrentUser( ) .getTodoLists( )" 
result="flowScope.todoLists" /> 
transition on="success" to="checkResultSize" /> 
</action-state> 

<deci si on -state id="checkResul tSize"> 

<if test="flowScope.todoLists.size() == 1" 

then="extractResul t" el se="show.todol ists" /> 
</decision-state> 

<act ion -state i d=" extract Res ill t"> 

<eval uate express ion="f 1 owScope. todoLi sts . i terator( ) .next( )" 
resul t="f 1 owScope. todoLi st"/> 

<transition on="success" to="show.todol i st" /> 
</action-state> 

<view-state id-"show.todol ists" view="todol ists"> 
transition on-"end" to-"end" /> 
<transition on="detail" to="show.todolist"> 
<eval uate 

expression="todoListsManager.findTodoList(requestParameters.id)" 
result="flowScope.todoList" /> 
</transition> 
</view-state> 

<view-state id="show.todol ist" view="todol ist"> 
<on-render> 

<evaluate expression="todoListAction.setupForm" /> 
</on- render> 

<transition on="save" to="todol ists"> 
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<evaluate expression-"todoListAction.bindAndValidate" /> 
<eval uate 

expressi on="todoListsManager.updateTodoList(todoListEdit)"/> 
<eval uate 

express ion="mess age Produce r.todo Li stUpda ted (messageContext)"/> 
</transition> 

<transition on="todos" to="todos" /> 
<transition on="todol ists" to="todol i sts" /> 
</view-state> 



<subf 1 ow-state id="todos" subf 1 ow="todo-f 1 ow"> 

<input name="todoList" value="flowScope.todoList"/> 

<transition on="end" to="show.todol ist" /> 
</subf 1 ow-state> 

<end- state id="end" view="wel come" /> 
</flow> 

La liste des Todos correspond au deuxieme flot, qui est lance en tant que sous-flot. La figure 8-6 
illustre ce flot d'affichage et de modification de Todos. 



Figure 8-6 

Flot de gestion des Todos 
d'une TodoList 



un seul Todo . 



« Action State» 
todos 




« End State» 
end 



end 



Ce flot a un deroulement identique a celui des TodoLi sts (recuperation des Todos, verification 
du nombre de resultats, liste ou detail, detail et modification). II necessite un TodoLi st en para- 
metre d'entree. 

Voici la definition XML de ce flot : 

<?xml version="1.0" encoding="UTF-8"?> 
<flow (...) > 

<secured attri butes="ROLE_USER" /> 

<input name="todoLi st" value="flowScope.todoList" /> 

<action-state id="todos"> 

<eval uate express ion=" todo Li stsManager . 

f indTodoLi st(fl owScope. todo Li st . 1 i stld) . getTodos( )" 
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result="flowScope. todos" /> 
transition on="success" to="checkResultSize" /> 
</action-state> 

<deci si on -state id="checkResul tSize"> 
<if test="flowScope.todos.size( ) == 1" 
then="extractResul t" el se="show.todos" /> 
</decision-state> 

<acti on -state id=" extract Res ult"> 

<eval uate expression-"f lowScope. todos . iterator ( ) .next( ) " 
resul t="f 1 owScope.todo"/> 

<transition on-"success" to="show.todo" /> 
</action-state> 

<view-state id="show. todos" view="todos" > 
transition on="detail" to="show.todo"> 
<evaluate expression-" 
todosManager. findTodo( request Parameters .id)" 
resul t="fl owScope.todo" /> 
</transition> 

<transition on="todol ist" to="end" /> 
</view-state> 

<view-state id="show.todo" view="todo"> 
<on-render> 

<evaluate expression="todoAction.setupForm" /> 
</on- render> 

<transition on="save" to="todos"> 
<evaluate expression="todoAction.bindAndValidate" /> 
<evaluate expression="todosManager.updateTodo(todoEdit)" /> 
<evaluate expression-" 
messageProducer . todoUpdated(messageContext ) " /> 

</transition> 

<transition on="todos" to="todos" /> 
<transition on="todol ist" to="end" /> 
</view-state> 

<end-state id="end" /> 

</flow> 



Implementation des entites 

Les differentes entites a implementer sont les actions et les vues. Concernant les vues, 
nous faisons le choix d'utiliser les technologies JSP et JSTL, ainsi que les fonctionnalites 
de gestion des vues du framework Spring MVC. Tudu Lists Core, en version JPA, est 
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utilisee pour les services metier. Une fine couche de securite est ajoutee, via Spring Secu- 
rity. 

Pour les formulaires, nous avons opte pour des FormActions. Ayant couvert largement ce sujet 
precedemment, nous n'entrerons pas dans le detail des implementations des formulaires. En 
revanche, nous decrivons des elements de configuration plus pousses de Spring Web Flow, 
recurrents dans les applications d'entreprise. 

Internationalisation 

L'internationalisation est fondee sur le systeme de MessageSource de Spring. Un 
ResourceBundl eMessageSource est declare dans le fichier correspondant a la configuration de 
Spring, web-application-config.xml : 

<bean id="messageSource" class-" 
org. spring-framework, context .support . ResourceBundl eMessageSource"> 



Le fichier /tudu/web/Messages.properties contient Fensemble des messages de l'applica- 
tion. Ce MessageSource est automatiquement detecte par Spring Web Flow, qui Futilise pour 
differents de ces elements. 

Par exemple, il est possible de construire des messages internationalises via un 
MessageBuilder : 

MessageBui 1 der builder = new MessageBui 1 der( ) ; 
messageContext . addMes sage (bui 1 der. info( ) . source( "todol i st" ) 

.code( "todol i st. updated" ) 

.defaultText( "Todo List updated" ) .buil d( ) 



Le parametre passe a la methode code fait reference a une cle se trouvant dans le fichier de 
proprietes. 

II est aussi possible d'utiliser les balises JSP de Spring MVC pour recuperer des libelles a 
partir du MessageSource configure : 

<%@taglib prefix="spring" 

uri="http: //www. springframework.org/tags" %> 
(...) 

<spring:message code="wel come. start" /> 

Messages de confirmation 

A des fins ergonomiques, nous affichons des messages de confirmation a Futilisateur. Pour 
cela, nous utilisons le MessageContext, auquel nous ajoutons des messages a la fin d'une 
transition : 

<view-state id="show.todolist" view="todol ist"> 




<property name="basename" val ue="tudu. web. Messages" /> 
</bean> 



); 



(...) 
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<transition on="save" to="todolists"> 

<evaluate expression="todoListAction.bindAndVal idate" /> 
<eval uate 

expression="todol_istsManager.updateTodol_ist( todoLi stEdit)"/> 
<eval uate 

expression="messageProducer .todoLi stUpdated(messageContext) "/> 

</transition> 
<transition on-"todos" to="todos" /> 
<transition on="todol i sts" to="todol ists" /> 
</view-state> 

Nous utilisons un Bean, le MessageProducer, dont la seule tache est d'ajouter des messages 
dans le MessageContext : 

package tudu.web; 

import org.springf ramework. binding. message. Mess ageBuilder; 
import org.springf ramework. binding. message. MessageContext ; 

public class MessageProducer { 

public boolean todoLi stUpdated(MessageContext messageContext) { 
MessageBuilder builder = new MessageBui 1 der( ) ; 
messageContext .addMessage(bui 1 der. info( ) . source ( "todol ist" ) 

.code( "todol i st .updated" ) 

.defaultTextC'Todo List updated" ) .bui ld( ) 

); 

return true; 

} 

(...) 

} 

Les messages sont ensuite affiches dans les vues : 

<c: for Each items=" $ {fl owRequestContext .messageContext . al 1 Messages} " 
var="message"> 
<p>$ {mess age. text }</p> 
</c:forEach> 

Ce systeme permet tres simplement de donner un retour a l'utilisateur sur ses differentes 
actions, ce qui est une bonne pratique ergonomique. 

Conversion et formatage dans les formulaires 

Les formulaires de notre etude de cas sont geres avec des sous-classes de FormAction. Pour 
chacun des champs des formulaires, un PropertyEditor est utilise pour effectuer les transfor- 
mations. En effet, quand le formulaire doit etre affiche, il faut formater chacune des valeurs 
(qui sont des objets Java : chaine de caracteres, date, etc.) pour permettre Faffichage sous 
forme de chaine de caracteres. 
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Quand le formulaire est sounds, il faut effectuer F operation inverse, c'est-a-dire convertir la 
chaine de caracteres du champ du formulaire en un objet Java. Le PropertyEditor est une 
interface fortement utilisee dans Spring, car ses implementations effectuent ces transforma- 
tions String vers Object et vice versa. 

Dans une FormAction, il est possible de referencer son propre registre de PropertyEditors, afin 
d'effectuer coiTectement les conversions ainsi que les formatages. II faut pour cela assigner 
une valeur a la propriete property Editor Registrar. C'est ce qui est fait dans TodoAction, qui a 
besoin de conversion specifique pour des champs de type date : 

publ i c TodoAction( ) { 

set FormObject Name ( "todoEdit" ) ; 

set P rope rtyEdi tor Regi strar(new Property Ed i to rs( ) ) ; 
setFormObjectScope(ScopeType. REQUEST) ; 

} 

Voici la definition de PropertyEditors : 
package tudu. validation; 

import java .text .Simpl eDate Format ; 
import java . uti 1 . Date ; 

import org. springf ramework. beans. Property Editor Registrar; 

import org. springf ramework. beans .Property Editor Registry; 

import org. springf ramework. beans .propertyeditors .CustomDateEditor; 

public class PropertyEditors implements PropertyEditorRegistrar { 

public void registerCustomEditors( 

PropertyEditorRegistry registry) { 
Simpl eDateFormat format = new Simpl eDateFormat( "yyyy-MM-dd" ) ; 
format. set Lenient (false) ; 
regi stry . regis terCustomEdi tor ( 

Date. class, new CustomDateEditor(format,true) 

); 

} 

} 

Le parametrage des PropertyEditors permet la bonne conversion des champs dans le formu- 
laire, sans oublier leur formatage. Ce mecanisme simple est aussi tres extensible, ce qui 
permet d'effectuer des conversions complexes, par exemple pour des objets de domaine. 



Conclusion 

Le framework Spring Web Flow a pour principale fonction d'adresser les problematiques liees 
a la navigation des applications Web. Sa mise en ceuvre n'est toutefois pas appropriee a tous 
les types d' applications Web. Certaines applications laissent a l'utilisateur le loisir de naviguer 
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librement alors que d'autres imposent des regies strictes de navigation. Spring Web Flow vise 
a faciliter le developpement de ces dernieres. 

Ce framework decouple et abstrait les differentes briques de mise en ceuvre des Hots Web, 
telles que flot, moteur d' execution de Hots et architecture existante (framework MVC, par 
exemple). Cette approche favorise la reutilisation des dots dans differents environnements. Le 
moteur peut egalement etre parametre sans impacter les flots et utilise sur differentes architec- 
tures. 

Spring Web Flow fournit un cadre robuste et flexible arm de definir un flot, d'implementer les 
actions et les vues, de les relier au flot et d'integrer le flot dans une architecture existante par 
le biais du framework Spring. II reprend d'ailleurs les concepts mis en ceuvre dans ce 
framework ainsi que son implementation MVC. 

Nous avons vu ici les principaux mecanismes de Spring Web Flow et privilegie son integra- 
tion avec Spring MVC. Cependant, il ne s'agit que d'une partie de ce framework riche et flexible, 
dont un livre entier ne suffirait pas a presenter Fensemble de ses possibilites. 

Notons simplement que Spring Web Flow propose une integration poussee avec JSF ainsi 
qu'un support pour les portlets. Pour avoir une idee de l'etendue des possibilites de Spring 
Web Flow, nous vous enjoignons a consul ter sa documentation de reference et les nombreux 
exemples se trouvant dans la distribution. 
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Utilisation d'AJAX 
avec Spring 



Depuis leurs debuts, les applications Web n'offrent a l'utilisateur final qu'une experience rela- 
tivement pauvre. Le cycle traditionnel requete/reponse sur lequel est fonde le Web ne permet 
pas la creation d' interfaces client elaborees, telles que nous pouvons en observer dans les 
applications de bureautique classiques. 

Le probleme vient essentiellement du fait que chaque action de l'utilisateur requiert un rechar- 
gement complet de la page HTML. Or c'est sur ce point qu'AJAX intervient en permettant le 
rechargement a chaud de portions d'une page HTML. 

Le terme AJAX (Asynchronous JavaScript and XML) renvoie a un ensemble de technologies 
differentes, toutes existantes depuis longtemps, mais qui, combinees intelligemment, permettent 
de changer radicalement notre mode de creation des interfaces Web. 

Le concept d'AJAX a ete lance debut 2005 par Jesse James Garrett dans un article devenu 
celebre, intitule « AJAX : a New Approach to Web Applications », disponible sur le site Web 
de sa societe Adaptive Path, a l'adresse http://www.adaptivepath.com/pubIications/essays/archi- 
ves/000385.php. 

Les technologies utilisees par AJAX, telles que JavaScript et XML, sont connues depuis long- 
temps, et, en realite, plusieurs societes faisaient deja de l'AJAX des 2000. La revolution 
actuelle provient de l'arrivee a maturite de ces technologies desormais largement repandues et 
livrees en standard avec les navigateurs Internet recents. Pour preuve, des entreprises telles 
que Google ou Microsoft se mettent a utiliser AJAX de maniere intensive. Des produits tels 
que Gmail ou Google Maps sont des exemples de technologies AJAX mises a la disposition 
du tres grand public. 
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Ce chapitre se penche en detail sur AJAX et introduit plusieurs techniques permettant de creer 
une application en suivant ses principes. Nous decrirons ainsi DWR, l'un des frameworks 
AJAX les plus populaires et qui a la particularite de s'integrer facilement a Spring. En particulier, 
ce framework nous permettra de publier des Beans Spring en JavaScript afin de manipuler 
directement des objets geres par Spring depuis un navigateur Internet. 

Nous indiquerons egalement la maniere d'utiliser le framework GWT, un outil de Google 
permettant de developper des applications Internet riches en se fondant sur le langage Java. 
Nous verrons qu'il est possible d'exporter des services de maniere distante afin qu'ils puissent 
etre utilises par des interfaces graphiques GWT. 

Nous soulignerons tout au long du chapitre les ecueils qui guettent le developpeur AJAX, 
technologie necessitant de maniere plus ou moins directe F utilisation du langage JavaScript. 
Ce langage n'etant pas directement lie a Spring, nous recommandons a ceux qui souhaitent 
approfondir le sujet la lecture de Fouvrage de Thierry Templier et Arnaud Goujeon, Java- 
Script pour le Web 2.0, paru aux editions Eyrolles. 



AJAX et leWeb 2.0 

Cette section entre dans le detail des technologies et concepts utilises avec AJAX. 

Nous commencerons par demystifier le terme marketing « Web 2.0 », tres souvent associe a 
AJAX, puis aborderons le fameux objet XMLHttpRequest, qui est au fondement d'AJAX et qui 
nous permettra de creer une premiere fonction AJAX simple. 



Le Web 2.0 

AJAX est souvent associe au Web 2.0. S'il s'agit la d'une campagne marketing tres bien 
orchestree, force est de reconnaitre que derriere les mots se cache une facon radicalement 
nouvelle de construire des applications Web. 

Le Web 2.0 est un concept plus global qu'AJAX, qui regroupe un ensemble d' aspects fonction- 
nels et metier. L' expression a ete concue par les societes O'Reilly et MediaLive International 
et a ete definie par Tim O'Reilly dans un article disponible a l'adresse http.V/www.oreilly- 
net. com/lpt/a/6228. 

Nous pouvons retenir de cet article que les applications Web 2.0 s'appuient sur les sept principes 
suivants : 

• Offre d'un service, et non plus d'une application packagee. 

• Controle d'une banque de donnees complexe, difficile a creer et qui s'enrichit au fur et a 
mesure que des personnes l'utilisent. 

• Implication des utilisateurs dans le developpement de 1' application. 

• Utilisation de 1' intelligence collective, les choix et les preferences des utilisateurs etant 
utilises en temps reel pour ameliorer la pertinence du site. 

• Choix de laisser les internautes utiliser 1' application comme un self-service, sans contact 
humain necessaire. 
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• Fonctionnement de F application sur un grand nombre de plates-formes, et plus seulement 
sur l'ordinateur de type PC (il y a aujourd'hui plus de terminaux mobiles que de PC ayant 
acces a Internet). 

• Simplicite des interfaces graphiques, des processus de developpement et du modele 
commercial. 

Nous comprendrons mieux cette philosophie en observant des sites emblematiques de ce 
Web 2.0, tels que les suivants : 

• Wikipedia, une encyclopedie en ligne geree par les utilisateurs eux-memes. Chacun est 
libre d'y ajouter ou de modifier du contenu librement, des groupes de benevoles se chargeant 
de relire les articles afin d'eviter les abus. 

• Les blogs, qui permettent a chacun de participer et de lier (mecanisme des trackbacks) des 
articles. 

• del.icio.us et Flickr, des sites collaboratifs dans lesquels les utilisateurs gerent leurs 
donnees en commun (des liens pour del.icio.us, des images pour Flickr). Ainsi, chacun 
paiticipe a Fenrichissement d'une base de donnees geante. 

Le Web 2.0 est done davantage un modele de fonctionnement collaboratif qu'une technologie 
particuliere. Pour favoriser l'interactivite entre les utilisateurs, ces sites ont besoin d'une inter- 
face graphique riche et dynamique. C'est ce que leur propose AJAX, avec sa capacite a 
recharger a chaud des petits morceaux de pages Web. Ces mini mises a jour permettent a 
l'utilisateur d'enrichir la base de donnees de F application sans pour autant avoir a recharger 
une page HTML entiere. 

Tudu Lists, notre application etude de cas, est un modeste representant du Web 2.0, 
puisqu'elle permet le partage de listes de taches entre utilisateurs, a la fois en mode Web (avec 
AJAX) et sous forme de flux RSS. 

Les technologies d'AJAX 

AJAX met en ceuvre un ensemble de technologies relativement anciennes, que vous avez 
probablement deja rencontrees. 

Un traitement AJAX se deroule de la maniere suivante : 

1. Dans une page Web, un evenement JavaScript se produit : un utilisateur a clique sur 
un bouton (evenement onCl i ck), a modifie une liste deroulante (evenement onChange), 
etc. 

2. Le JavaScript qui s'execute alors utilise un objet particulier, le XMLHttpRequest ou, si 
vous utilisez Microsoft Internet Explorer, le composant ActiveX Microsoft.XMLHTTP. 
Cet objet n'est pas encore standardise, mais il est disponible sur Fensemble des navi- 
gateurs Internet recents. Situe au coeur de la technique AJAX, il permet d' envoy er une 
requete au serveur en tache de fond, sans avoir a recharger la page. 
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3. Le resultat de la requete peut ensuite etre traite en JavaScript, de la me me maniere 
que lorsque nous modifions des morceaux de page Web en DHTML. Ce resultat est 
generalement du contenu renvoye sous forme de XML ou de HTML, que nous 
pouvons ensuite afficher dans la page en cours. 

AJAX est done un melange de JavaScript et de DHTML, des technologies utilisees depuis 
bien longtemps. L'astuce vient essentiellement de ce nouvel objet XMLHttpRequest, lui aussi 
present depuis longtemps, mais jusqu'a present ignore du fait qu'il n'etait pas disponible sur 
suffisamment de navigateurs Internet. 

Voici un exemple complet de JavaScript utilisant l'objet XMLHttpRequest pour faire un 
appel de type AJAX a un serveur. C'est de cette maniere que fonctionnaient les anciennes 
versions de Tudu Lists (avant l'arrivee de DWR, que nous detaillons plus loin dans ce 
chapitre). Cet exemple illustre le reaffichage a chaud d'une liste de taches, ainsi que 
l'edition d'une tache : 

<scri pt type="text/javascript"> 

var req; 

var fragment; 

/** 

* Fonction AJAX generique pour utiliser XMLHttpRequest. 
*/ 

function retrieveURL(url ) { 

if (window. XMLHttpRequest) { 
req = new XMLHttpRequest( ) ; 
req.onreadystatechange = miseAJourFragment; 
try { 

req.openCGET", url , true); 
} catch (e) { 

al ert( "<fmt: mess age key="todos .ajax.error"/>" ) ; 

} 

req . send(nul 1 ) ; 
} // Utilisation d'ActiveX, pour Internet Explorer 
else if (window. ActiveXObject) { 

req = new Acti veXObjectt "Mi crosoft .XMLHTTP" ) ; 

if (req) { 

req.onreadystatechange = miseAJourFragment; 
req.openCGET", url, true); 
req.send( ) ; 

} 

} 

} 



/** 

* Met a jour un fragment de page HTML. 
*/ 

function mi seAJourFragment( ) { 

if (req.readyState == 4) { // requete completee 
if (req. status = 200) { // reponse OK 
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document . get El ementBy Id (fragment ) 

.innerHTML = req.responseText; 

} else { 

alert("<fmt:message key="todos.ajax.error"/> " + 

req. status) ; 

} 

} 

} 

/** 

* Affiche la liste des taches. 
*/ 

function af f i chel_esTaches( ) { 
fragment='todosTable' ; 

retrievelIRK '${ctx} /a jax/manageTodos. action?' + 

' 1 i stId=${todoLi st . 1 istId}&method=render' ) ; 

} 

/** 

* Edite une tache. 
*/ 

function editeUneTache(id) { 
fragment='editFragment' ; 

retrieveURL( ' ${ctx} /a jax/manageTodos . acti on?todoId=' + 

escape(id) + '&method=edit' ) ; 

} 

( ... ) 
</script> 

Dans cet exemple, des fragments de page sont mis a jour a chaud, avec du contenu HTML 
renvoye par le serveur. 

Comme nous pouvons le deviner en regardant les URL envoyees au serveur, ces requetes 
HTTP sont traitees par des controleurs de Spring MVC, le parametre method etant utilise par 
ces derniers arm de selectionner la methode a executer (voir le chapitre 7 pour plus d' infor- 
mations sur le traitement de ces requetes). 

Le HTML renvoye par les controleurs de Spring MVC est simplement affiche dans des 
elements HTML. En l'occurrence, la methode innerHTML utilisee plus haut permet de changer 
le HTML present dans des elements <span> : 

I <span id-"editFragment"X/span> 
<span id="todosTable"X/span> 
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Cette utilisation tres simple d'AJAX reclame deja une assez bonne connaissance de Java- 
Script. Suffisante pour un site Web simple, elle souffre cependant des lacunes suivantes : 

• Elle necessite beaucoup de code JavaScript et devient difficile a utiliser des lors que nous 
voulons faire plus que simplement afficher du HTML. 

• Elle pose des problemes de compatibilite d'un navigateur a un autre. 

Afin de faciliter F utilisation de ce type de technique, un certain nombre de frameworks ont vu 
le jour, tels Dojo, DWR, JSON-RPC, MochiKit, SAJAX, etc. 

Le framework AJAX DWR (Direct Web Remoting) 

DWR est un framework AJAX tres populaire dans la communaute Java proposant une interes- 
sante integration du framework Spring. DWR permet de presenter tres facilement en Java- 
Script des JavaBeans geres par Spring. II est ainsi possible de manipuler dans un navigateur 
Internet des objets s'executant cote serveur. 

DWR est un framework Open Source developpe par Joe Walker, qui permet d'utiliser aise- 
ment des objets Java (cote serveur) en JavaScript (cote client). 

Fonctionnant comme une couche de transport, DWR permet a des objets Java d'etre utilises a 
distance selon un principe proche du RMI (Remote Method Invocation). Certains autres 
frameworks AJAX, comme Rico, proposent des bibliotheques beaucoup plus completes, avec 
des effets speciaux souvent tres impressionnants. Pour ce type de resultat, DWR peut etre 
utilise conjointement avec des bibliotheques JavaScript non specifiques a Java EE, telles que 
script, aculo. us, une bibliotheque d' effets speciaux tres populaire parmi les utilisateurs de 
Ruby On Rails. 

Signe de la reconnaissance de DWR par la communaute Java, des articles ont ete publies sur 
les sites developpeur de Sun, IBM et BEA. Dans le foisonnement actuel de frameworks 
AJAX, nous pouvons raisonnablement affirmer que DWR est Fun des plus avances 

Publie sous licence Apache 2.0, ce framework peut etre utilise sans probleme, quelle que soit 
F application que vous developpez. 

Principes de fonctionnement 

DWR est compose de deux parties : du JavaScript, qui s'execute cote client dans le navigateur 
de Futilisateur, et une servlet Java, laquelle est chargee de traiter les requetes envoyees par le 
JavaScript. 

DWR permet de presenter des objets Java en JavaScript et de generer dynamiquement le 
JavaScript necessaire a cette fonctionnalite. Les developpeurs JavaScript ont ainsi la 
possibilite d'utiliser de maniere transparente des objets Java qui tournent dans le serveur 
d' applications et qui ont done, par exemple, la possibilite d'acceder a une base de donnees. 
Cela augmente considerablement les possibilites offertes a Finterface graphique d'une 
application. 
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La figure 9-1 illustre Fappel d'une fonction Java depuis une fonction JavaScript contenue 
dans une page Web. 



Figure 9-1 
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function showEditTodo(todold) { 
todos.getTodoByld( reply, todold); 

} 



var reply = function(todo) { 
document.forms 
editTodoFormdescription. value = 
todcdescription ; 

} 
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Java 



t ud u web .d wr. imp I.TodosDwrlmpI 



public Todo getTodoByld(String 
todold) { 

Todo todo = 
todosManager.findTodo(todold); 
return todo; 
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Afin de mieux illustrer notre propos, nous allons detailler comment fonctionne une version 
simplifiee du code permettant d'editer une tache a chaud dans Tudu Lists. 

Suite au clic de souris d'un utilisateur sur le texte « edit », a droite d'une tache, le JavaScript 
suivant s' execute : 

function showEditTodo(todoId) { 
Effect. Appear( 'editTodoDiv' ) ; 
todos.getTodoById(reply. todold) ; 
document .forms .editTodoForm.descri ption.focus( ) ; 

} 

Ce code affiche le layer DHTML d'edition d'une page (il s'agit d'un effet special de 
script. aculo. us), puis appelle un objet Java distant et donne le focus a la description de la tache 
editee. 

Le code d'appel a la fonction Java est compose d'un objet todo, genere automatiquement par 
DWR, qui prend les deux parametres suivants en fonction : 

• reply, la fonction callback JavaScript. II s'agit done non pas d'une variable passee en argu- 
ment, mais d'une fonction JavaScript qui s'execute apres F execution de Fappel a l'objet Java. 

• todold, l'identifiant de la tache a editer, qui est passe en argument a la fonction Java distante. 
Ce code appelle la fonction Java distante getTodoByld de l'objet todo presente par DWR : 
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package tudu.web.dwr.impl ; 

(...) 

/** 

* Implementation du service tudu. service. TodosManager. 
*/ 

public class TodosDwrlmpl implements TodosDwr { 
(...) 

public RemoteTodo getTodoById(String todold) { 
Todo todo = todosManager.findTodo(todoId) ; 
RemoteTodo remoteTodo = new RemoteTodo( ) ; 
remoteTodo .setDescri pt ion (todo. get Descript ion ( ) ) ; 
remoteTodo .setPriori ty( todo. getPri ori ty ( ) ) ; 
if (todo.getDueDate( ) != null) { 
Simpl eDateFormat formatter - 

new Simpl eDateFormat( "MM/dd/yyyy" ) ; 

String formattedDate 

= formatter. format (todo. getDueDate( ) ) ; 
remoteTodo. setDueDate( formattedDate) ; 
} else { 

remoteTodo. setDueDateC") ; 

} 

return remoteTodo; 

} 

} 

Ce code Java recherche la tache demandee dans la couche de service de 1' application, laquelle 
fait a son tour un appel a la couche de persistance afin qu'elle retrouve les informations en 
base de donnees. Pour des raisons de securite, que nous verrons plus tard dans ce chapitre, ce 
code cree un objet Java specifique pour la couche DWR, et cet objet est retourne au client. 

Au retour d'execution du code Java, la fonction callback reply, que nous avons vue plus haut, 
s' execute : 

var reply = function(todo) { 

document .forms .editTodoForm.description.val ue 

= todo. description; 
document. forms. editTodoForm. priority. value - todo. priority ; 
document. forms. editTodoForm.dueDate. value = todo.dueDate; 

} 

Etant une fonction de rappel, elle prend automatiquement un seul argument, F objet retourne 
par la fonction JavaScript getTodoBy Id. Cela revient a dire qu'elle utilise l'objet Java retourne 
par la methode getTodoByld, qui represente une tache. II est ensuite aise de recopier les attributs 
de cet objet dans les champs HTML du formulaire presentant la tache ainsi editee. 
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Configuration 

Vu de Fexterieur, DWR se compose d'une servlet et d'un fichier de configuration, nomme 
dwr.xml, autorisant l'appel de methodes d'objets Java de maniere distante tout en gerant de 
maniere transparente la conversion des types utilises. Sa configuration n'est pas particulie- 
rement complexe, d'autant que le framework fournit une excellente interface de test. 

La servlet DWR 

DWR est tout d'abord une servlet, qu'il convient de configurer dans F application Web en 
cours. Les differents JAR fournis dans la distribution de DWR doivent etre copies dans le 
repertoire WEB-INF/lib, et la servlet DWR, correspondant a la classe DWRServlet, doit etre 
configuree dans le fichier WEB-INF/web.xml, comme toutes les servlets : 

(...) 
<servl et> 

<servl et-name>dwr-invoker</servl et-name> 
<servl et-cl ass> 

org. di rectwebremoting. servlet. DWRServlet </servlet-cl a ss> 
<init-param> 

<param-name>debug</param-name> 
<param-val ue>fal se</param-val ue> 
</init-param> 
</servl et> 
(...) 

<servlet-mapping> 

<servl et-name>dwr-invoker</servl 

<url -pattern>/secure/dwr/*</url - 
</servlet-mapping> 
(...) 

Dans cette configuration, le parametre debug peut etre mis a true afin d'avoir des informa- 
tions plus precises sur le fonctionnement de DWR. Par ailleurs, l'adresse d'acces a DWR 
est /secure/dwr/*. Cette derniere est bien entendu librement configurable mais, dans Tudu 
Lists, nous preferons la prefixer par /secure/*, afin qu'elle soit protegee par Spring Security. 

Le fichier dwr.xml 

DWR est configure via un fichier, qui se nomme par defaut dwr.xml et est localise dans le 
repertoire WEB-INF de F application Web. Le nom de ce fichier est configurable grace aux 
parametres d' initialisation de la servlet DWR : 

(...) 
<servl et> 

<servl et-name>dwr-user-i invoke r</servl et-name> 
<servl et-cl ass> 

org.di rectwebremoting.servlet.DWRServlet</servlet-class> 
<init-param> 

<param-name>conf ig-user</param-name><— Q 
<param-val ue>WEB- INF/dwr-user .xml </param-val ue> 
</init-param> 
</servl et> 



et-name> 
pattern) 
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Le nom du parametre doit imperativement commencer par config. C'est pourquoi, dans 
Fexemple ci-dessus, nous Favons appele conf i g-user (Qi). L'interet de cette manipulation est 
d'autoriser plusieurs fichiers de configuration, et ainsi plusieurs instances differentes de la 
servlet DWR : une instance pour les utilisateurs normaux (config-user) et une pour les admi- 
nistrateurs (config-admin). En leur donnant des adresses differentes, nous pouvons utiliser la 
securite standard de Java EE pour ne permettre qu'aux utilisateurs ayant un role donne d' utiliser 
une instance de DWR. 

Un fichier dwr.xml possede la structure decrite dans le code suivant : 

<dwr> 

<init><^Q 

<creator id="..." cl ass=" . . . "/> 
<converter id="..." class=" . . . "/> 
</1m't> 

<allow><^© 

<create creator-" . . . " javascript-" . . . " scope="..."> 

<param name="..." val ue=" . . . "/> 
</create> 



<convert convertor=" . . . " match=" . . . "/> 
</allow> 



<signatures><— Q 
( ... ) 

</signatures> 
</dwr> 

La partie delimitee par la balise i ni t (Q) n'est generalement pas utilisee. Elle sert a instancier 
les classes utilisees plus bas dans le fichier de configuration, dans le cas oil le developpeur 
souhaiterait utiliser ses propres classes au lieu de celles foumies en standard par DWR. Nous 
allons voir que les classes livrees avec DWR sont cependant largement suffisantes pour une 
utilisation de l'outil, fut-elle avancee. 

La section delimitee par la balise allow (Q) indique a DWR quelles classes il a le droit 
d'instancier et de convertir. Cette section est la plus importante du fichier, si bien que nous 
allons detailler les elements de creation et de conversion qui la composent. 

Pour instancier une classe, DWR utilise une entite de creation, definie dans le fichier de confi- 
guration par la balise create. Cette entite permet d'instancier une classe de plusieurs manieres 
et de Fassocier a une ressource JavaScript generee a la volee. Le code suivant decrit Futilisation 
de la balise create : 

<al 1 ow> 

<create creator="new" javascri pt="Exampl e"> 

<param name="class" value="tudu.web.dwr.Example"/> 
</create> 
</allow> 

Dans cet exemple, l'entite de creation de type new permet d'instancier une classe et de l'asso- 
cier a un objet JavaScript nomme Exampl e. II s'agit de l'entite de creation la plus simple, mais 
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il en existe d'autres, en particulier pour acceder a des Beans Spring, ce que nous verrons dans 
l'etude de cas. L'objet Example une fois presente ainsi en JavaScript, ses methodes peuvent 
etre appelees depuis le navigateur client. Cependant, il est possible que lesdites methodes utili- 
sent comme arguments, ou comme objets de retour, des classes complexes, telles que des 
collections ou des JavaBeans. Ces classes doivent des lors etre converties d'un langage a F autre. 

Pour convertir une classe Java en JavaScript et vice versa, DWR utilise des convertisseurs. En 
standard, DWR est fourni avec des entites de ce type permettant la conversion des types Java 
primaires, des dates, des collections et des tableaux, des Beans, mais aussi d' objets plus 
complexes, comme des objets DOM ou Hibernate. 

Pour des raisons de securite, certains convertisseurs complexes, comme celui gerant les 
Beans, ne sont pas actives par defaut. Pour convertir un Bean en JavaScript, il faut autoriser sa 
conversion par l'intermediaire de la balise convert : 

<al 1 ow> 

<convert converter-'bean" 

match="tudu. web. dwr. bean. RemoteTodol_ist"/> 

<convert converter-'bean" 

match="tudu.web.dwr . bean . RemoteTodo"/> 

</allow> 

Utilisation du JavaScript dans les JSP 

Une fois la servlet DWR correctement configuree, il est necessaire d' acceder au code Java- 
Script genere dynamiquement par le framework depuis les pages JSP. Pour cela, il faut impor- 
ter dans les JSP les deux bibliotheques propres a DWR : 

<script type="text/javascript" 

src="<c:url val ue="/secure/dwr/engine. js"/>"X/script> 

<script type="text/javascript" 

src="<c: url val ue="/secure/dwr/uti 1 . js"/>"X/script> 

Dans l'application Tudu Lists, cette importation est realisee dans le fichier WEB-INF/jspf/ 
header.jsp. 

Notons que ces deux fichiers JavaScript sont fournis par la servlet DWR et qu'ils n'ont pas a 
etre ajoutes manuellement dans l'application Web. 

II faut ensuite importer les fichiers JavaScript generes dynamiquement par DWR et qui 
represented les classes Java decrites dans dwr.xml. Voici l'exemple de la classe 
tudu. web. dwr. impl .TodosDwrlmpl , qui est configuree dans dwr.xml pour etre utilisable dans 
une page Web par l'intermediaire de l'objet JavaScript todos : 

<script type=" text/ javascript" 

src="<c: url val ue="/secure/dwr/interface/todos . js"/>"> 
| </script> 

Ce fichier doit etre importe depuis la servlet DWR mappee dans Tudu Lists par l'adresse 
/secure/dwr/*, a laquelle nous ajoutons le suffixe interface. 
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Test de la configuration 

La configuration etudiee ci-dessus est relativement complexe, 1' importation et l'utilisation du 
JavaScript genere posant generalement probleme aux nouveaux utilisateurs. C'est pourquoi 
DWR est fourni avec une interface de test tres bien concue. 

Pour la mettre en place, il faut modifier la configuration de DWR dans le fichier web.xml, afin 
de passer en mode debug (Q) : 

<servl et> 

<servl et-name>dwr-i nvokeK/servl et-name> 
<servl et-cl ass> 

org.directwebremoting.servlet.DWRServlet</servlet-class> 
<init-param> 

<param-name>debug</param-name> 

<param-val ue>true</param-val ue><— Q 
</init-param> 
</servl et> 

Notons bien que cette configuration ne doit pas etre utilisee en production, car elle faciliterait 
la tache d'une personne malveillante. 

Une fois ce parametrage effectue, nous pouvons acceder a des pages de test via l'adresse de 
base de la servlet DWR, qui, dans notre etude de cas, est http://127.0.0.1:8080/tudu/secure/dwr/. 
Ces pages listent les objets presentes par DWR, ainsi que leurs methodes respectives. Ces 
dernieres peuvent etre appelees directement tout en specifiant d'eventuels parametres. Les 
objets retournes sont egalement affiches dans la page. Le code source de ces pages fournit une 
aide precieuse pour l'utilisation de DWR. 

La figure 9-2 illustre la page affichant la classe TodosDWRImpl, Tune des deux classes configurees 
avec DWR dans Tudu Lists. 
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Methods For: todos (tudu.web.dwr Jmpl.TodosDwrlmpl) 

To use this class in your javascript you will need (be following script includes: 

■sacript typo-' text/ javaacript' age- ■ /tuari/ancurn/ch/r/ Intnrraew/tadoa. ta ' «^/aerlpt>| 
taccipt typo*' toxt/ Javaaccipt ' «: r. - • j d i ■ :u ■ a nq - ■■ )a*x/acript> 

In addition then- is an optional uu'lity script: 

<accipt typ*-' t«xt/ iavaaccipt ' arc" ■ : jd j • »v: j: v dx: j* - : )a*x/acript> 

Replies fnim DWR an: shown with a yeltnw haekoniund if they arc simple or in an alen !x» otherwise. 
The inputs arc evaluated as Javascript so strings must be quoted before execution. 

There arc 21 declared methods: 

• sctUscr.Managctt XiasfiJ 

(Wamiajr NoCoovertertortudu.ier*i« U-erMaoixcr fae btlouO 

• setTodoLlstsManagerf ): 

rWamlnf: No Convener tor iudu-i*rvi« TodoljMvManatrr Sec below 

• delete 1 odot ~ ); uwual 

• complete Todo( " ); u«ci«l 

• rcopcn Todoi " X i»K»ii| 

• scfrodoaNUnagctt ); u«c*el 

(W»mins No Convener tor tudu rcr»Kr I'odoiMinijrer See txtourl 

• gclCuncnfl "odoLists{ ); u«c.»l 

• gclTodoByldf ~ ); u«eu»l 
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Utilisation de I' API Servlet 

DWR permet de s'abstraire de l'API Servlet, ce qui simplifle generalement grandement le 
travail a effectuer. Nous utilisons directement des arguments passes en parametres des 
methodes au lieu de les extraire depuis l'objet correspondant a la requete ou un objet de 
formulaire. 

L'API Servlet reste neanmoins parfois incontournable pour peu que nous voulions stacker des 
attributs dans la session HTTP, utiliser JAAS pour la securite ou acceder au contexte de 
1' application Web. Pourtoutes ces utilisations, DWR stocke dans une variable ThreadLocal les 
objets HttpServl etRequest, HttpServl etResponse, HttpSession, Servl etContext et 
ServletConfig. 

Pour acceder a l'objet associe a la requete HTTP en cours, il suffit d'ecrire le code suivant : 

WebContext context = org.di rectwebremoting.WebContextFactory.get( ) ; 
HttpServl etRequest request = context . getHttpServl etRequest( ) ; 

L'acces a cette variable en ThreadLocal n'est bien entendu possible que pour les fils d' execution 
correspondant a des requetes traitees avec DWR. 



Gestion des performances 

A premiere vue, l'utilisation d'AJAX ameliore les performances. Au lieu de demander au 
serveur de recharger des pages completes, nous nous contentons de lui demander le strict 
minium. 

Cependant, des que nous maitrisons cette technique, nous sommes rapidement pousses a 
multiplier les requetes cote serveur. Le site devient des lors plus riche, plus « Web 2.0 », mais, 
en contrepartie, les requetes HTTP se trouvent multipliers. 

Cout de DWR en matiere de performances 

En lui-meme, DWR n'affecte que de facon negligeable les performances cote serveur. Le 
serveur d' applications, le temps reseau ou les traitements metier sont normalement bien plus 
import ants. 

Joe Walker, l'auteur de DWR, a effectue plusieurs tests qui lui permettent de proposer les opti- 
misations suivantes : 

• Les appels de moins de 1 500 octets peuvent tenir dans un seul paquet TCP, ce qui ameliore 
sensiblement l'utilisation du reseau. II est done important de n'echanger que le strict 
minimum de donnees. 

• L'utilisation de parametres de la JVM privilegiant les objets a faible duree de vie apporte un 
gain de performances, du moins avec Tomcat. Avec une JVM Sun, il s'agit de l'option 
-XX:NewSize. 
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Utilisation de fonctions batch pour les requetes 

II est possible de grouper des requetes DWR arm de diminuer le nombre d'allers-retours entre 
le client et le serveur. Nous retrouvons cette optimisation a plusieurs endroits dans Tudu Lists, 
en particulier lors de l'ajout d'un todo : 

DWREngine.beginBatch( ) ; 

todos . addTodo ( repl y RenderTabl e , 

listld, description, priority, dueDate); 

todos .getCurrentTodoLi sts( replyCurrentTodoLi sts ) ; 
DWREngine.endBatch( ) ; 

La fonction beginBatchO permet de placer les requetes suivantes en queue et de ne les 
envoyer qu'une fois la fonction endBatch( ) executee. 



Integration de Spring et de DWR 

Le framework DWR propose une ingenieuse integration a Spring, qui permet d'utiliser direc- 
tement des Beans Spring en JavaScript. Avec la version 2 du framework, un espace de 
nommage dedie est mis a disposition afin de simplifier 1' exposition des services via la techno- 
logie. 

Dans ce contexte, il convient d'utiliser un createur DWR dedie nomme spring. Cette approche 
permet d'indiquer a Foutil que F instance du Bean utilise est geree par Spring. Ce createur 
prend done en parametre l'identifiant du Bean a utiliser. 

A moins d'utiliser une servlet DispatcherServlet de Spring MVC, DWR met a dispo- 
sition une servlet dediee pour 1' utilisation conjointe de DWR et Spring. Cette servlet 
correspond a la classe DwrSpringServl et localisee dans le package org.direct- 
webremoti ng . spring. 

Le code suivant illustre la mise en ceuvre de cette classe (Q) avec F activation du mode debug 
(Q) et un mappage /dwr/* (Q) dans le fichier web.xml : 

(...) 
<servl et> 

<servl et-name>dwr</servl et-name> 
<servl et-cl ass> 

org.di rectwebremoting.spring.DwrSpringServlet<— Q 
</servl et-cl ass> 
<init-param><— Q 

<param-name>debug</param-name> 
<param-val ue>true</param-val ue> 
</init-param> 
</servl et> 
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<servlet-mapping> 

<servl et-name>dwr</servl et-name> 

<url -pattern>/dwr/*</url -pattern><— Q 
</servlet-mapping> 

Comme l'illustre le code suivant, dans la configuration du contexte applicatif associe a 
l'application Web, il convient d'utiliser Fespace de nommage de DWR (Q) afin de definir un 
bloc de configuration (Q) ainsi que le controleur de l'outil (©) : 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xmlns:dwr-" http://www.di rectwebremoting.org/schema/spring-dwr" 
xsi : schema Location-" http://www.spr ingframework.org/schema /beans 
http://www.springframework.org/schema/beans/spring-beans.xsd 

http://www.di rectwebremoting.org/schema/spring-dwr<— Q 
http://www.di rectwebremot ing.org/schema/spring-dwr- 2. 0.xsd"> 

<dwr:configuration/><— Q 

<dwr:controller id="dwrController" debug="true" /><— Q 

(...) 

</beans> 

Par la suite, deux approches sont envisageables, l'une permettant d'utiliser une configuration 
existante de Beans, l'autre s'effectuant au sein meme de leur configuration dans Spring. 

Dans la premiere approche, le bloc de configuration precedent doit etre etendu afin de preciser 
les Beans a exposer en AJAX par F intermediate de DWR. A ce niveau, il faut configurer un 
createur de type spring pour les Beans choisis. 

Le code suivant illustre la configuration de cette approche tiree de l'application Tudu Lists. La 
balise create de l'espace de nommage peut etre utilisee (©) avec le parametre beanName par 
1' intermediate de la sous-balise pa ram (Q) : 

(...) 

<dwr:configuration> 

<dwr:create javascript="todo_l ists" type="spring"><— Q 

<dwr:param name="beanName" val ue="todoLi stsDwr"/><— Q 
</dwr:create> 

<dwr:create javascript="todos" type-"spri ng"><— Q 
<dwr:param name="beanName" val ue="todosDwr"/><— Q 

</dwr:create> 
</dwr: configuration) 
(...) 

Comme ces deux services utilisent des objets de type TodoList et Todo, des convertisseurs 
DWR doivent etre configures afin de permettre leur transformation d' objets JavaScript en 
objets Java et inversement. 
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Cette configuration s'effectue par le biais de la balise convert. Le type bean doit etre utilise 
pour les objets du modele. Cette balise peut etre utilisee pour le service ou a un niveau global, 
comme dans le code suivant : 

<dwr:configuration> 
(...) 

<dwr:convert type="bean" 

cl a ss=" core. tudu. domain. model .Todo"/> 
<dwr:convert type="bean" 

cl ass-" core. tudu. domain. model .TodoLi st"/> 
</dwr:configuration> 

Dans l'exemple precedent, nous publions en JavaScript les Beans Spring todoListsDwr et 
todosDwr par Fintermediaire de DWR. Ces Beans ont bien entendu ete configures au prealable 
dans un contexte Spring, nomme WEB-INF/applicationContext-dwr.xml. 

Voici la configuration du Bean todoLi stsDwr : 

<bean id="todol_istsDwr" 

class="tudu.web.dwr.impl .TodoLi stsDwrlmpl "> 

<property name="todoListsManager" ref ="todoListsManager" /> 
<property name="userManager" ref ="userManager" /> 
</bean> 

Les Beans Spring ainsi configures sont accessibles en JavaScript. En voici un exemple d' utili- 
sation tire de la page JSP WEB-INF/jsp/todo_lists.jsp, qui sert a gerer les listes de taches. 
Une fois l'inclusion de la ressource DWR (Q) relative au service realisee, Fobjet JavaScript 
correspondant peut etre utilise afin d'executer en AJAX ses methodes (Q) : 

<script type="text/javascript"<— Q 

src-"<c:url val ue="/secure/dwr/interf ace/todo_l ists . js"/>"> 
</script> 

<script type="text/javascript"> 
(...) 

// Ajout d'un utilisateur a la liste selectionnee. 
function addTodoLi stUser( ) { 

var listld = document. forms. editListForm. listld. value; 

var login = document. forms. editListForm. login. value; 

todo_l i sts .addTodoLi stUser( 

replyAddTodoListUser, listld, login);<— Q 

} 

(...) 
</script> 

La seconde facon d'exposer des Beans par l'intermediaire de DWR se realise au sein meme de 
leur configuration dans Spring. Dans ce cas, la balise remote doit etre utilisee afin de preciser 
le nom de l'objet JavaScript correspondant. Cette approche soustend que le developpeur a la 
main sur les fichiers de configuration Spring des services metier. 
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A ce niveau, les convertisseurs precedemment configures dans la balise configuration 
peuvent etre utilises ou de nouveau etre specifies en se fondant toujours sur la balise convert. 

Le code suivant illustre la mise en ceuvre de cette approche fondee sur la balise remote (Q) 
pour le Bean Spring d'identifiant todoLi stsDwr : 

<bean id="todoListsDwr" 

class="tudu.web.dwr.impl .TodoLi stsDwrlmpl "> 

<property name="todoListsManager" ref ="todoLi stsManager" /> 

<property name="userManager" ref ="userManager" /> 

<dwr: remote javascript="simpl eService"><— Q 
</bean> 

Le framework GWT (Google Web Toolkit) 

La mise en ceuvre d' applications AJAX comporte de nombreuses difficultes, notamment pour 
le support des differents navigateurs, qui ne gerent pas tous le JavaScript de la meme facon. 

L'interface graphique Web s'enrichissant continuellement, il devient vite problematique de 
maintenir et de faire evoluer des applications de ce type pour un ensemble de navigateurs. 
Heureusement, differentes solutions permettent de contourner cette difficulte. 

GWT (Google Web Toolkit), un framework populaire adressant cette problematique, est 
disponible en Open Source depuis la fin de Fannee 2007. II propose une approche originale 
permettant d'ecrire des applications Web riches en Java, un compilateur dedie se chargeant de 
les convertir en JavaScript. 

Principes de fonctionnement 

La mise en ceuvre d' applications Web riches n'est pas une chose facile. Elle necessite tout 
d'abord une solide maitrise des technologies Web et des langages JavaScript, CSS et HTML. 
Bien que la plupart des developpeurs Java connaissent les bases de ces langages, le marche 
manque cruellement de competences JavaScript. 

De plus, le langage JavaScript etant interprete et non type, il est impossible de connaitre a 
l'avance les types utilises dans les traitements. Ajoutons que le developpement et le debogage 
d' applications de ce type sont d'autant plus ardus qu'il n'existe pas de veritable environnement de 
developpement dedie a JavaScript. 

Afin d'adresser ces difficultes, le framework GWT a fait le choix d'ecrire les traitements des 
applications Web riches executes dans les navigateurs non pas en JavaScript, mais en Java. De 
cette maniere les problemes decrits ci-dessus ne se posent plus. En contrepartie, le code Java 
ne peut etre execute dans les navigateurs. 

Pour remedier a ce probleme, le framework GWT propose un compilateur dedie afin de trans- 
former ce code en JavaScript tout en integrant les specificites des principaux navigateurs. De 
ce fait, les environnements de developpement tels qu'Eclipse peuvent etre utilises ainsi que 
toutes les fonctionnalites correspondantes. C'est le cas notamment des aides au developpement 
telles que la completion et le debogage. 
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Un des gros avantages de l'outil GWT est que le compilateur Java vers JavaScript fournit en 
natif des optimisations du code JavaScript genere. Cela favorise un code plus robuste, 
optimise pour le navigateur utilise. 

Ces optimisations sont les suivantes : 

• Compression avec GZip des fichiers echanges. 

• Allegement de la taille des fichiers JavaScript par l'intermediaire de noms de variables et 
fonctions JavaScript raccourcis. 

• Mecanisme de chargement en tache de fond des scripts en se fondant sur une iframe cachee. 

• Utilisation de la mise en cache des navigateurs. 

• Chargement par le navigateur uniquement des fonctions dont il a besoin pour ses trai- 
tements. 

• Generation lors de la compilation du code JavaScript optimise pour chacun des navigateurs. 
Une fois charge, le navigateur garde en cache le code approprie. 

Ces optimisations entrainent un temps de chargement reduit du code JavaScript utilise pour 
F application Web riche. 

En parallele de ces mecanismes, le framework GWT offre deux modes distincts d' execution 
en fonction du contexte : 

• Hosted (ou gere) : 1' application est executee en tant que bytecode Java. Ce mode facilite les 
phases de codage, compilation, test et debogage. Ce mode est exclusivement utilise au sein 
de Fenvironnement de developpement. 

• Web : le navigateur lit simplement le code genere par le compilateur GWT et l'interprete 
naturellement. 



Configuration de GWT 

GWT se fonde sur le concept de module afin de modulariser les differents traitements, qu'ils 
soient internes a une application ou qu'ils correspondent a des bibliotheques GWT. 

A cet effet, GWT impose une structuration rigoureuse des packages et de la localisation de 
certaines entites. 

Un module GWT est compose des elements suivants : 

• Classes Java relatives a Finterface graphique Web ainsi qu'aux objets de donnees et aux 
interfaces des services distants utilises. Ces classes sont converties en code JavaScript lors 
de la phase de compilation precedemment decrite, et ce code est execute dans un navigateur 
Web. Une classe particuliere doit etre definie en tant que point d'entree du module. 

• Classes Java relatives a 1' implementation des services distants utilises. Ces classes ne sont 
pas compilees en JavaScript puisqu'elles sont executees au niveau d'un serveur d' applications. 
Elles ont la responsabilite de repondre aux requetes AJAX de GWT. 

• Ressources Web fournissant le point d'entree de F application et ressources relatives aux 
styles et a du code JavaScript supplemental. 
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• Fichier de configuration du module permettant de definir les elements GWT utilises, les 
eventuels fichiers de style et JavaScript ainsi que la classe du point d'entree. 

Afin de mettre en ceuvre ces elements, GWT impose la structuration en packages suivante : 

• Packages de base relatifs au module (non imposes). 

• Packages specifiques au module, qui doivent etre cl i ent pour les classes relatives a l'inter- 
face graphique Web, public pour les ressources Web et server pour les classes mettant a 
disposition des services distants. 

• Fichier de configuration, qui doit etre defini a la racine du module et dont le nom obeit a la 
syntaxe <module>.gwt.xml, ou module correspond au nom du module choisi. Le module 
peut etre utilise a partir d'autres modules en se fondant sur 1'identifiant <package- 
module>.<module>. 

Afin de creer les structures des projets et des modules, le framework GWT fournit deux outils 
en ligne de commande, projectCreator et applicationCreator. Une option eclipse permet 
egalement de generer les metadonnees de configuration pour Fenvironnement de developpement 
Eclipse. 

Le code suivant illustre l'utilisation de ces deux commandes : 

$ mkdir tudu-gwt 
$ cd tudu-gwt 

$ projectCreator -eclipse TuduGwt 

$ applicationCreator -eclipse TuduGwt tudu. web. gwt. client. TuduGwt 

Le fichier de configuration du module correspond a un fichier XML possedant la structure 
suivante : 

<modul e> 

<!-- Specification des elements utilises 

(GWT et biliotheques) --> 
<inherits name=" ... "/><—© 
<inherits name=" ... "/><—© 

<!-- Specification d'elements CSS et JavaScript --> 
<script src=" . . . "/><— Q 
<stylesheet src=" ... "/><—© 

<!-- Specification de servlets pour les tests --> 
<servlet path="..." cl ass=" ... "/><—© 

<!-- Specification du point d'entree --> 
<entry-point cl ass=" . . . "/><— Q 
<!-- Proprietes --> 

<extend-property name="l ocal e" val ues="f r"/> 
<extend-property name="l ocal e" val ues="en"/> 
</modul e> 
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Tout d'abord, les modules de GWT et externes doivent etre specifies par F intermediate des 
balises inherits (Q). Les valeurs doivent correspondre aux identifiants de modules relatifs a 
la structure decrite ci-dessus. En voici un exemple de configuration : 

<i inherits name=" com. google. gwt. user. User "/> 
| <inherits name-"com.gwtext.GwtExt"/> 

Les balises script et stylesheet (Q) permettent de definir des scripts JavaScript et des 
feuilles de style CSS a utiliser dans le module GWT. Les references peuvent correspondre 
aussi bien a des fichiers presents dans le repertoire pub! i c du module qu'a des fichiers distants 
accessibles sur Internet. 

La balise servlet (Q) permet de specifier des servlets a utiliser dans les tests au niveau du 
Hosted Mode. 

Le point d'entree du module est specifie par la balise entry-point (Q), qui reference la classe 
correspondante. Comme cette classe correspond a l'interface graphique Web, elle doit se trou- 
ver dans un sous-package de client et doit implementer l'interface EntryPoi nt de GWT localisee 
dans le package com. google. gwt. core. client. 

Le code suivant illustre une classe de point d'entree implementant l'interface EntryPoi nt (Q) 
et sa methode onModuleLoad coiTespondante (Q) : 

package tudu.web.gwt.cl ient; 
(...) 

public class TuduEntryPoint implements EntryPoint {<— O 
(...) 

public void onModul eLoad( ) {<— Q 

II Les traitements de construction de l'interface graphique 

// Web riches sont inities dans cette methode 

(...) 

} 

} 

La configuration de cette classe en tant que classe de point d'entree du module est illustree 
dans le code suivant : 

<en try -point cl ass="tudu.web.gwt.client.TuduEntryPoint"/> 

Interfaces graphiques Web riches 

Sans entrer dans tous les details du framework GWT, nous presentons ci-apres ses principaux 
composants graphiques. 

Le tableau 9-1 recapitule les composants de base fournis par GWT afin de construire des 
interfaces graphiques Web riches. 

Le framework GWT permet le positionnement des elements en offrant un mecanisme fusion- 
nant les concepts de panel et de layout. Les quatre types de panels suivants sont mis a 
disposition : simple, complexe, tableau et avec separation. 
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Tableau 9-1. Composants de base fournis par GWT 



Composant 


Description 


Button 


bouton H 1 ML 


Grid, HTMLTable, FlexTable 


Permet la mise en oeuvre de differents types de tableaux. 


HTML 


rcl lllcl Uc pidUci UU CUUc n 1 ML 


Hyperl ink 


Lien hypertexte 


Image et ImagGBundl e 


Permet d'inserer une portion d'image ou une image entiere. Le second 
composant permet de regrouper plusieurs images afin de minimiser les 
echanges reseau. 


Label 


Zone d'affichage 


ListBox 


Permet la mise en oeuvre de listes de valeurs. 


MenuBar 


Barre de menus 


SuggestBox 


Zone avec proposition de contenu a la volee 


TextBox 


Zone de saisie 


Tree 


Permet la mise en oeuvre d'arbres. 


Ces differents elements sont recapitules au tableau 9-2. 


Tableau 9-2. Principaux composants relatifs aux panels fournis par GWT 


Composant 


Description 


Absol utePanel 


Permet un positionnement en absolu des composants. 


DisclosurePanel 


Une encoche permet de demasquer les elements contenus. 


DockPanel 


Permet d'organiser les composants en fonction de cotes (nord, ouest, 
centre, estet sud). 


FlowPanel et StackPanel 


Permettent respectivement de positionner des composants en se fondant 
sur le concept HTML f 1 ow et de definir des menus deroulants. 


FormPanel 


Permet de positionner des elements de formulaire et d'interagir avec le 
serveur afin de manipuler les donnees contenues. 


Horizontal Panel et Verti cal Panel 


Permet d'aligner des elements horizontalement ou verticalement. 


HTMLPanel 


Permet d'integrer dans des applications GWT des pages de sites externes. 


PopupPanel et DialogPanel 


Permettent de mettre en ceuvre respectivement des menus contextuels et 
des fenetres au sein meme du navigateur. 


Spl itPanel 


Permet de definir des zones redimensionnables. 


TabPanel 


Permet de mettre en oeuvre des onglets. Un die sur le bouton de I'onglet 
permet d'afficher son contenu. 



Les panels sont avant tout des composants correspondant a des conteneurs de composants et 
peuvent done etre combines afin de realiser des positionnements avances de composants. 
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Le code suivant illustre la maniere de creer la structure de F application Tudu en GWT en se 
fondant sur les composants graphiques et panels decrits aux tableaux 9-1 et 9-2 : 

public void onModul el_oad( ) { 



Root Panel .get( "main" ) .add (ma in Panel ) ; 

//Panel affichant les lists disponibles 
Panel listsPanel = new Verti cal Panel () ; 
ma in Panel . addd istsPanel , DockPanel .WEST) ; 

//Panel affichant les todos de la liste selectionnee 
Panel todosPanel = new Verti cal Panel () ; 
mainPanel .addUodosPanel , DockPanel .CENTER) ; 
currentTodoList Label . set Sty 1 eName( "todo-1 ist-1 abel " ) ; 
todosPanel . add(currentTodoLi s t Label ) ; 

Panel newTodoPanel = new Horizontal Panel () ; 

Label newTodoLabel = new Label ( "Create a new to-do : "); 

final TextBox newTodoDescription = new TextBoxO; 
newTodoDescription .addKeyboardLi stener( 

new KeyboardLi stenerAdapter( ) { 
public void onKeyPress(Widget sender, 

char keyCode, int modifiers) { 
if (keyCode = KeyboardLi stener.KEY_ENTER) { 

SerializableTodo todo = new Seri al izabl eTodo( ) ; 
todo. set Description (newTodoDescri pti on.getText( ) ) ; 



newTodoPanel .add(newTodoLabel ) ; 
newTodoPanel .add(newTodoDescription) ; 
todosPanel .add(newTodoPanel ) ; 
todosPanel .add (table) ; 

newTodoDescri pti on. set Focus ( true) ; 
getAl lTodoLi sts( ) ; 

} 



GWT integre un mecanisme permettant de realiser des appels AJAX afin d'echanger des 
donnees entre l'interface graphique Web et les traitements serveur. Au niveau de la partie 
cliente, le mecanisme mappe le fonctionnement correspondant de JavaScript et se fonde sur 
des methodes de rappel. 




(...) 



createTodoOnServer(todo) ; 
currentTodoList. getTodos( ) .add(todo) ; 
newTodoDescri pti on. setText( "" ) ; 



}); 



Appels distants 
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La mise en ceuvre des appels distants avec GWT s'appuie sur les differentes entites suivantes : 

• Interface du service distant specifiant les differentes methodes utilisables du service. 

• Interface AJAX de GWT correspondant a F interface precedente, mais integrant les meca- 
nismes de rappel d'AJAX. Elle specifie egalement les methodes utilisables de maniere 
distante et asynchrone. 

• Implementation du service distant mettant en ceuvre les traitements correspondants. 

Les interfaces ci-dessus doivent etre disponibles au niveau de la partie cliente de GWT et etre 
localisees dans un sous-package du package client. L' implementation etant executee cote 
serveur, elle doit etre presente dans un sous-package du package server. 

GWT impose aux interfaces des services correspondants d'etendre son interface 
RemoteService du package com. google. gwt. user. client.rpc. Cela permet de specifier qu'il 
s'agit d'une interface pour un service accessible par Fintermediaire de GWT. 

Le code suivant illustre la mise en ceuvre d'une interface de ce type : 

public interface TuduGwtRemoteService extends RemoteService { 
String createTodo(String listld, Seri al i zabl eTodo sTodo); 
void updateTodo(SerializableTodo sTodo); 
void deleteTodo(SerializableTodo sTodo); 
SerializableTodoList getTodoList(String listld); 
Li st<Seri al izabl eTodoLi st> getAl lTodoLi sts( ) ; 

} 

L implementation du serveur doit implementer cette interface et, de base, etendre la classe 
RemoteServiceServlet du package com. google. gwt. user. server. rpc. Cette derniere classe 
permet de specifier le service en tant que servlet, cette classe doit etre definie dans le fichier 
web.xml. 

Le code suivant fournit un exemple d' implementation de F interface precedente : 

public class TuduGwtRemoteServi celmpl 
extends RemoteServiceServlet 
implements TuduGwtRemoteService { 

public String createTodo(String listld, 

SerializableTodo sTodo) { 
Todo todo = new TodoO; 

todo. set Description (sTodo . getDescription( ) ) ; 
todo. setPriority(sTodo.getPriori ty ( ) ) ; 
todosManager . createTodod i stld, todo) ; 
sTodo. setTodoId(todo.getTodoId( ) ) ; 
return todo.getTodoId( ) ; 

} 

public void updateTodo(SerializableTodo sTodo) { 

Todo todo = todosManager. findTodo(sTodo.getTodoIdO); 
todo. set Description (sTodo . getDescription( ) ) ; 
todo. setPriority(sTodo.getPriori ty( ) ) ; 
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todosManager.updateTodo(todo) ; 

if (todo.isCompletedO && IsTodo.isCompletedO) { 

todosManager . reopenTodo(sTodo. getTodoId( ) ) ; 
} else if ( !todo. isCompl eted( ) && sTodo.isCompletedO) { 

todosManager . compl eteTodo(sTodo.getTodoId( ) ) ; 

} 

} 

(...) 

} 

En parallele de Finterface du service, une interface asynchrone associee doit etre definie. 
Cette derniere reprend les methodes definies precedemment en leur ajoutant un parametre 
correspondant a l'entite de rappel, cette derniere correspondant au type AsyncCallback du 
package com. google. gwt. user. client. rpc. II est a noter que ces methodes ne possedent plus 
desormais de retour. 

L'interface coirespondante a l'exemple precedent est decrite dans le code suivant : 

public interface TuduGwtRemoteServi ceAsync { 

void createTodo(String listld, Serial izableTodo sTodo, 

AsyncCallback callback); 
void updateTodo(SerializableTodo sTodo, 
AsyncCallback callback); 
void deleteTodo(SerializableTodo sTodo, 

AsyncCallback callback); 
void getTodoLi st(String listld, AsyncCallback callback); 
void getAHTodoLists(AsyncCallback callback); 

} 

Une fois ces entites definies, des appels distants AJAX peuvent etre mis en ceuvre au sein de 
GWT. A ce stade, l'entite cle correspond a la classe GWT, laquelle permet de creer au sein de 
l'interface graphique Web l'entite cliente permettant d'appeler le service de maniere distante. 

Le code suivant illustre la creation d'une entite d'appel du service distant. L' utilisation de la 
methode create offre la possibilite de creer cette instance (Q), sur laquelle l'adresse d'acces 
peut etre specifiee (Q). L'appel des methodes du service se realise par 1' intermediate de 
l'interface asynchrone (©) et d'une entite de rappel (0) : 

TuduGwtRemoteServi ceAsync tuduGwtRemoteServi ce =<— O 

( TuduGwtRemoteServi ceAsync) GWT. create ( 
TuduGwtRemoteService. class) ; 

Servi ceDefTarget endpoint = (ServiceDefTarget)tuduGwtRemoteService; 
endpoint .setServiceEntryPoint(GWT.getHostPageBaseURL( )<— Q 
+ "secure/tudu_l ists_remote_service" ) ; 

(...) 

tuduGwtRemoteServi ce.getAl lTodoLi sts( 

new AsyncCal 1 back<Li st>( ) {<— Q 
public void onSuccess( Li st al ITodoLists) {<— Q 
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currentTodoLi st = (SerializableTodoList) 

allTodoLists.get(O); 
getTodoLi st( currentTodoLi st.getLi stld( ) ) ; 



} 



public void onFai 1 uredhrowabl e caught) {<— Q 

Window. alertCERROR : The server could not be reached : ' 

+ caught. getMessage( )) ; 

} 



}); 



Integration de Spring et GWT 

Les frameworks GWT et Spring ne fournissent ni Fun ni F autre de fonctionnalites permettant 
d'utiliser les deux outils conjointement. 

Pour pallier cette limitation, deux approches sont possibles : en utilisant des implementations 
de la classe RemoteServiceServlet au sein de Spring MVC, ou en se fondant sur le module 
serveur de la bibliotheque GWT Widget, disponible sur le site du projet, a Fadresse http://gwt- 
widget. sourceforge.net. 

Dans le premier cas, un controleur generique peut etre developpe afin de deleguer les traitements 
au service distant GWT. 

Dans le second cas, le module serveur de Foutil GWT Widget, disponible a Fadresse http:// 
gwt-widget.sourceforge.net, permet d'exposer un Bean configure dans Spring en tant que 
service GWT par Fintermediaire de la classe GWTRPCServiceExporter localisee dans le 
package org . gwtwi dgets . server . spri ng. 

Cette approche necessite un point d'entree afin de definir le mappage entre les adresses et les 
services exportes. Pour cela, Spring MVC doit etre mis en ceuvre par Fintermediaire de la 
servlet DispatcherServlet. 

L' exportation des services se realise dans le fichier XML de configuration associe a la servlet 
de Spring MVC. Le code suivant illustre la configuration d'un service TuduGwtRemoteService 
adapte pour GWT, mais independant des API du framework : 

<bean id="tudul_i stsRemoteServi ce" cl a ss=" org. gwtwi dgets . server 

. spring .GWTRPCServiceExporter"> 
<property name="service" ref="tuduLi stsRemoteServi ce" /> 
<property name=" service Interfaces" 

val ue=" tudu. web. service. TestServi ce"/> 

</bean> 

II est a noter que toutes les classes des objets echanges lors de Fappel AJAX doivent se trouver 
sous le package client du module GWT courant. 

La configuration de Faiguillage se realise par Fintermediaire de F implementation Simpl eUrl - 
HandlerMapping de Finterface HandlerMapping de Spring MVC, comme FiUustre le code suivant : 

<bean id="url Mappi ng" cl ass=" org. spri ngf ramework. web. servl et 
. handl er .Simpl ellrl Handl erMapping"> 
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<property name="mappings"> 
<map> 

<entry key="/secure/tudu_l ists_remote_servi ce" 
val ue-ref-"tuduListsRemoteService" /> 

</map> 
</property> 
</bean> 

Mise en oeuvre d'AJAX avec DWR dans Tudu Lists 

Nous utilisons la technologie AJAX dans les deux pages principales de Petude de cas Tudu 
Lists, la page de gestion des listes de todos et la page de gestion des todos. 

Tudu Lists utilise DWR, integre a Spring de la maniere detaillee precedemment, afin d'editer, 
ajouter, supprimer ou afficher des entites gerees dans la couche de service de l'application et 
persistees avec JPA. 

Fichiers de configuration 

Les fichiers de configuration sont ceux detailles precedemment : 

• web.xml dans le repertoire WEB-INF, qui sert a configurer la servlet DWR. 

• applicationContext-dwr.xml dans le repertoire WEB-INF, qui gere les Beans Spring 
presentes avec DWR. 

• dwr-servlet.xml dans le repertoire WEB-INF, qui est le fichier de configuration de DWR. 

Chargement a chaud d'un fragment de JSP 

Nous allons commencer par l'exemple le plus simple, le chargement a chaud d'un fragment 
HTML genere cote serveur par une JSR Lutilisation d'AJAX ne necessite pas obligatoire- 
ment F utilisation et la transformation de donnees en XML. II est possible de generer une 
chaine de caracteres cote serveur et de F afficher directement dans la page HTML en cours. 

Dans le monde Java EE, le moyen naturel pour generer du HTML etant un fichier JSR voici 
de quelle maniere transferer une JSP en AJAX. Cette technique s' applique aux deux fichiers 
WEB-INF/jspf/todo_lists_table.jsp et WEB-INF/jspf/todos_table.jsp. Nous allons etudier 
plus precisement ce deuxieme fichier, qui est essentiel a la generation de la principale page de 
l'application. 

Voyons pour cela le JavaScript contenu dans la page WEB-INF/jsp/todos.jsp qui va utiliser 
ce fragment de JSP : 

function renderTabl e( ) { 

var listld = document .forms .todoForm. 1 istld. val lie; 
todos. renderTodos(replyRenderTable, listld) ; 

} 

var replyRenderTable = function(data) { 
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DWRUtil .setValue( 'todosTable' , 

DWRUtil .toDescn'ptiveString(data, 1) 

); 

} 

La fonction renderTablet ) utilise Fobjet todos, qui est un Bean Spring presente par DWR, 
pour generer du HTML. La variable reply RenderTabl e est une fonction callback prenant auto- 
matiquement en parametre l'argument de retour de la fonction renderTodos. Elle utilise des 
methodes utilitaires fournies par DWR pour afficher cet argument de retour dans l'entite 
HTML possedant l'identifiant todosTabl e. 

Ces fonctions utilitaires, fournies par le fichier util.js, ont ete importees via le header de la 
JSP WEB-INF/jspf/header.jsp. Elles servent a faciliter l'affichage, mais il n'est pas neces- 
saire pour autant de les utiliser. 

Les deux fonctions utilisees ici sont les suivantes : 

• DWRUtil .setValuedd, value), qui recherche un element HTML possedant Fidentifiant 
donne en premier argument et lui donne la valeur du second argument. 

• DWRUtil .toDescn'ptiveString(objet, debug), une amelioration de la fonction toString qui 
prend en parametre un niveau de debug pour plus de precision. 

La partie la plus importante du code precedent concerne la fonction todos . renderTodos ( ), qui 
prend en parametre la fonction callback que nous venons d'etudier ainsi qu'un identifiant de 
liste de todos. 

Comme nous pouvons le voir dans le fichier WEB-INF/dwr-servlet.xml, cette fonction est en 
fait le Bean Spring todosDwr : 

(...) 

<dwr: configuration 

<dwr:create javascript="todos " type="spring"> 

<dwr:param name="beanName" val ue="todosDwr"/> 
</dwr:create> 
(...) 

</dwr:configuration> 
Ce Bean est lui-meme configure dans WEB-INF/applicationContext-dwr.xml : 

<bean id="todosDwr" class="tudu.web.dwr.impl .TodosDwrlmpl "> 

La fonction appelee est au final la fonction renderTodos(String listld) de la classe 
TodosDwrlmpl . 

Cette methode utilise la methode suivante pour retourner le contenu d'une JSP : 

return WebCon text Factory .get( ) . forwardToString( "/WEB-INF/jspf /todos_tabl e. jsp" ) ; 

Cette methode permet done de recevoir le resultat de F execution d'une JSP sous la forme 
d'une chaine de caracteres que nous pouvons ensuite inserer dans un element HTML de la 
page grace a la fonction DWRUtil .setVal ue( ), que nous avons vue precedemment. 
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Cette technique evite d'utiliser du XML, qu'il faudrait parcourir et transformer cote client. 
Elle permet d'utiliser un resultat qui a ete obtenu cote serveur. En ce sens, meme si ce n'est 
pas une technique AJAX « pure », elle presente l'avantage d'etre simple et pratique. 



Modification d'un tableau HTML avec DWR 

Dans l'etape suivante de notre etude de cas, nous utilisons plus completement l'API de DWR 
en modifiant les lignes d'un tableau HTML. Cette technique permet de creer des tableaux 
edi tables a chaud par l'utilisateur. Ce dernier peut en changer les lignes et les cellules sans 
avoir a subir le rechargement de la page Web en cours. 

La page utilisee pour gerer les todos, WEB-INF/jsp/todos.jsp, possede un menu sur la 
gauche contenant un tableau des listes de todos possedees par l'utilisateur. Ce tableau est gere 
en AJAX grace au JavaScript suivant : 

function renderMenuO { 
todos. getCurrentTodoLi sts (replyCurrentTodoLi sts) ; 

} 

var replyCurrentTodoLi sts = function(data) { 
DWRUti 1 . removeAl 1 Rows ( "todoLi stsMenuBody " ) ; 
DWRUti 1 . addRows( "todoLi stsMenuBody" , data , 
[ selectTodoListLink ]); 

} 

function selectTodoListLink(data) { 

return "<a href-\" javascript : renderTabl eLi stld ( ' " 
+ data . 1 i stld + n, )\">" + data. description + "</a>"; 

} 

Nous utilisons les deux elements importants suivants : 

• renderMenu, qui est la fonction appelee a d'autres endroits de 1' application pour generer 
le tableau : au chargement de la page, lors de la mise a jour des todos, ainsi que par une 
fonction lui demandant un rafraichissement toutes les deux minutes. Les listes de todos 
pouvant etre partagees avec d'autres utilisateurs, les donnees doivent etre reguliere- 
ment rafraichies. Cette fonction appelle un Bean Spring presente avec DWR, dont nous 
connaissons maintenant bien le fonctionnement, et utilise une variable callback. 

• replyCurrentTodoLi sts, qui est une fonction callback prenant comme parametre le resultat 
de la methode todos. getCurrentTodoLists( ). Cette methode, qui appartient a la classe 
tudu.web.dwr.impl .TodosDwrlnpl, retourne un tableau de JavaBeans de type 
tudu. web. dwr. bean. RemoteTodoList. Afin de retourner un tableau de listes de todos, nous 
n'utilisons pas directement le JavaBean tudu. domain. model .TodoList. Presenter en Java- 
Script un objet de la couche de domaine pourrait en effet presenter un risque en matiere de 
securite. Pour cette raison, seuls des Beans specifiques a la presentation sont autorises dans 
DWR via les balises create du fichier WEB-INF/dwr-servlet.xml. 
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Cette derniere fonction fait appel aux classes utilitaires de DWR suivantes, qui permettent de 
gerer les elements de tableau : 

• DWRUtil .removeAHRows(id), qui enleve toutes les lignes du tableau HTML possedant 
l'identifiant passe en argument. 

• DWRUtil .addRowsdd, data, eel 1 Funcs ), qui ajoute des lignes au tableau HTML possedant 
l'identifiant passe en premier argument. Les donnees utilisees pour construire ce tableau 
sont passees dans le deuxieme parametre de la fonction et sont un tableau d'objets. Le troi- 
sieme parametre est un tableau de fonctions. Chacune de ces fonctions prend en parametre 
un element du tableau, ce qui permet de creer les cellules. 

Dans notre exemple, le tableau n'ayant qu'une colonne, une seule fonction, selectTodo- 
ListLink(data), prend en parametre un JavaBean, tudu. web. dwr. bean. RemoteTodoLi st, 
converti au prealable en JavaScript. 

Nous pouvons ainsi utiliser le JavaScript pour obtenir Fidentifiant et la description de la liste 
a afficher dans la cellule du tableau. 



Utilisation du patron open-entity-manager-in-view avec JPA 

Le patron open-entity-manager-in-view permet d'utiliser l'initialisation tardive, ou lazy- 
loading, pour de meilleures performances en dehors des services metier. Cette methode, utile 
dans le cadre des JSP, reste entierement valable pour des composants AJAX. 

C'est de cette maniere que le Bean Spring tudu. web. dwr. impl .TodoListsDwrlmpl peut recher- 
cher la liste des utilisateurs dans sa methode getTodol_istsUsers( ). En effet, la liste des utili- 
sateurs est une collection en initialisation tardive, e'est-a-dire qu'elle n'est reellement recherchee 
en base de donnees qu'au moment ou elle appelee. 

Afin de permettre F utilisation de l'initialisation tardive, il nous faut configurer le filtre de 
servlets de JPA arm qu'il traite les requetes envoyees a DWR de la meme maniere qu'il traite 
les requetes envoyees a Spring MVC. Cela se traduit par un mappage dans le fichier /WEB- 
INF/web.xml : 

<filter> 

<filter-name>JPA EntityManager In View Filter</filter-name> 
<f i 1 ter-cl ass> 

org.springf ramework.orm. jpa 

.support .OpenEntityManagerlnViewFi 1 ter 
</f i 1 ter-cl ass> 
</filter> 

<!-- Configuration pour Spring MVC --> 
<filter-mapping> 

<f i 1 ter-name> JPA EntityManager In View Filter</filter-name> 

<url -pattern>*.action</url -pattern> 
</filter-mapping> 
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<!-- Configuration pour DWR --> 
<filter-mapping> 

<filter-name> JPA EntityManager In View Filter</filter-name> 

<url -pattern>/secure/dwr/*</url -pattern> 
</filter-mapping> 

Mise en oeuvre d'AJAX avec GWT dansTudu Lists 

La mise en oeuvre de GWT dans l'application Todo Lists necessite l'ecriture complete des 
traitements de 1' interface graphique en Java. Pour ce faire, differents composants graphiques 
sont utilises afin de definir le positionnement des elements de cette interface et de creer les 
zones de donnees. Ces dernieres correspondent aussi bien a des libelles et des zones de texte 
que des listes deroulantes et des tableaux. 

L'application integre egalement des services distants compatibles avec GWT permettant 
d'interagir avec la base de donnees. Ces services permettent d'exposer les services existants 
de l'application Todo Lists. 

Nous detaillons dans les sections suivantes la maniere d'utiliser GWT afin de mettre en oeuvre 
une couche de presentation Web riche. 

Fichiers de configuration 

L'application met en oeuvre des fichiers de configuration aussi bien au niveau de GWT que de 
l'application serveur permettant de repondre aux appels AJAX. 

Le fichier de configuration GWT pour 1' application Todo Lists se trouve dans le package 
tudu.web.gwt et se nomme TuduGwt.gwt.xml. Comme l'illustre le code suivant, il permet 
de referencer le module de base de GWT (Q) et de configurer le point d' entree de l'appli- 
cation Q) : 

<modul e> 

<!-- Reference les modules de GWT --> 

<inherits name= ' com. google. gwt. user. User '/><—© 

<!-Specifie le point d'entree de l'application --> 
<en try -point class='tudu.web.gwt.cl ient.TuduGwt ' /><— Q 
</modul e> 

II est interessant de noter qu'au meme niveau que ce fichier, dans le package tudu . web . gwt, se 
trouvent les packages cl i ent, publ i c et server contenant respectivement les classes de l'inter- 
face graphique, les ressources Web et les classes de l'application serveur. 

La configuration de la partie serveur de l'application se realise dans le fichier web.xml du 
repertoire WEB-INF. Comme nous mettons en oeuvre la servlet Di spatcherServl et de Spring 
MVC, un fichier supplemental correspondant au contexte associe doit etre defini. Ce fichier 
se nomme tudu-gwt-servlet.xml et se trouve egalement dans le repertoire WEB-INF. 
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Comme l'indique le code suivant, le fichier web.xml contient uniquement la configuration du 
contexte applicatif de 1' application Web (Q) ainsi que celle de cette servlet (Q), cette 
derniere etant mappee sur /gwt/* : 

<web-app (...)> 

<context-param><— Q 

<param-name>contextConf i gLocation</param-name> 
<param-val ue> 
cl asspath: /tudu/domain/appl icationContext- jpa .xml , 
cl asspath: /tudu/servi ce/appl icationContext .xml , 
cl asspath :/tudu/security/appl icationContext -security .xml 
</param-val ue> 
</context-param> 



<1 i stener><— Q 

<1 i stener-cl ass> 

org.springf ramework. web. con text. Context Loader Listener 

</listener-class> 
</l i stener> 



<servl et><— Q 

<servlet-name>tudu-gwt</servl et-name> 

<servlet-class> 

org.springf ramework. web. servlet. Di spat cherServlet 

</servl et-cl ass> 
</servl et> 



<servl et-mappi ng><— Q 

<servl et-name>tudu</servl et-name> 

<url -pattern>/gwt/*</url -pattern> 
</servlet-mapping> 
</web-app> 

Comme le montre le code suivant, le fichier tudu-gwt-sevlet.xml permet de configurer 
1' exposition du service distant (Q) utilise par GWT pour ses requetes AJAX ainsi que son 
adresse d'acces (©) : 

<bean id="url Mappi ng" cl ass="org. springf ramework. web. servl et 

. handl er .Simpl ell rl Hand! erMapping"> 

<property name="mappings"> 
<map> 

<entry key="/testServi ce"<— Q 

val ue-ref="tuduGwtRemoteServiceExporter"/> 

</map> 
</property> 
</bean> 



<bean id="tuduGwtRemoteServi ce" 

cl as s="tudu. web. gwt. server. TuduGwtRemoteServi celmpl > 
<property name="todosManager" ref="todosManager"/> 
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<property name="todol_istsManager" ref="todol_i stsManager"/> 
<property name="userManager" ref="userManager"/> 
</bean> 

<bean id="tuduGwtRemoteServi ceExporter"<— Q 

cl ass="org.gwtwidgets.server.spring.GWTRPCServiceExporter"> 
<property name="servi ce" ref="tuduGwtRemoteServi ce" /> 
<property name="servi ce Interfaces" 

val ue="tudu.web.service.TestService"/> 
</bean> 

Avec GWT, F utilisation du patron de conception open-entity-manager-in-view se realise de la 
meme maniere qu'avec Foutil DWR. Pour plus de precision, reportez-vous a la section 
« Utilisation du patron open-entity-manager-in-view avec JPA » de ce chapitre. 

Detaillons maintenant les mecanismes mis en ceuvre au niveau de F interface graphique Web. 



Construction de /'interface graphique avec GWT 

La construction se realise dans la classe TuduGwt definie dans le fichier TuduGwt.gwt.xml en 
tant que point d'entree de Fapplication. Cette classe implemente Finterface EntryPoint de 
GWT et met en ceuvre la methode onModuleLoad, methode etant appelee au chargement de 
Fapplication. 

Le panel principal de Fapplication est de type DockPanel. II permet de specifier les listes a 
gauche de Finterface et les todos correspondant a la liste selectionnee au centre. Des panels de 
type Vertical Panel sont ensuite utilises afin d'afficher ces informations. 

Le panel principal est ajoute a la page Web de Fapplication en se fondant sur la classe 
RootPanel et sa methode statique get. 

Le code suivant illustre la mise en ceuvre de la structure generale de Fapplication GWT dans 
la methode onModul eLoad : 

DockPanel mainPanel = new DockPanel () 
RootPanel . get ( "main" ) . add (ma i n Panel ) ; 

//Panel montrant les listes disponibles 
Panel listsPanel = new Verti cal Panel () ; 
mainPanel .adddistsPanel , DockPanel .WEST); 

//Panel montrant les todos courants 

Panel todosPanel = new Verti cal Panel () ; 

mainPanel .addUodosPanel , DockPanel .CENTER) ; 

cur rentTodo List Label . setStyl eName( "todo-1 i st-1 abel " ) ; 

todosPanel .add(currentTodoListLabel ) ; 

Panel newTodoPanel = new Horizontal Panel () ; 

Label newTodoLabel = new Label ( "Create a nouveau todo : "); 



final TextBox newTodoDescription 



= new TextBox( ) ; 
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(...) 



newTodoPanel . add(newTodol_abel ) ; 
newTodoPanel .add(newTodoDescription) ; 
todosPanel .addtnewTodoPanel ) ; 
todos Panel . add(tabl e) ; 

newTodoDescript ion. set Focus (true) ; 

Une fois la structure de l'application creee, les listes de todos sont chargees par l'interme- 
diaire de la methode getAllTodoLists. Comme l'indique le code suivant, cette derniere 
methode realise a cet effet une requete AJAX (Q), et le premier element est affiche (Q) : 

private void getAllTodoListsO { 

AsyncCal 1 back callback = new AsyncCal 1 back<Li st>( ) { 
public void onSuccess(List allTodoLists) { 

currentTodoList = (SerializableTodoListX— Q 
allTodoLists. get(O); 
getTodoLi st( currentTodoList .get Li stld( ) ) ;<— O 

} 



Le descriptif de la liste ainsi que les todos correspondant sont alors charges avec l'appel de la 
methode getTodoLi st (©), cette derniere se fondant sur la methode printTodoList (Q). Le 
tableau affichant les todos correspondant est mis a jour en se fondant sur la methode 
setWidget (Q) de la classe FlexTable de GWT. Enfin, une requete AJAX (©) est mise en 
ceuvre afin de recuperer les donnees : 

private void printTodoList( ) {<— © 
tabl e.clear( ) ; 

for (int todolndex = 0; todolndex < 



public void onFai 1 ure(Throwabl e caught) { 
Window. alert( 

"ERROR : The server could not be reached : " 
+ caught. getMessageO); 



); 



tuduGwtRemoteService.getAl ITodoLi ststcal 1 back) ;<— Q 



currentTodoLi st . getTodos( ) .size( ) ; todoIndex++) { 
table. setWidget(todoIndex, 0,<— Q 

writeDescription(todoIndex) ) ; 
table. setwidget(todoIndex, 1,<— Q 

createCheckBoxWidget(todoIndex) ) ; 
table. setWidget(todoIndex, 2,<— Q 

createDeleteWidget(todoIndex)) ; 



I Les frameworks de presentation 
| Partie II 

private void getTodol_ist(String listld) {<— Q 

AsyncCal 1 back callback = new AsyncCal 1 back( ) { 
public void onSuccess(Object result) { 

currentTodoLi st = (SerializableTodoList) result; 
currentTodoLi stLabel .setText( 

currentTodoLi st .get Name ( ) ) ; 

printTodol_ist( ) ; 

} 

public void onFai 1 ure(Throwabl e caught) { 
Window. alertt 

"ERROR : The server could not be reached : " 
+ caught. getMessage( )) ; 

} 

}; 

tuduGwtRemoteServi ce. getTodoLi st(l istld, cal 1 back) ;<— Q 

} 

Nous allons maintenant decrire la mise en ceuvre des interactions avec l'utilisateur afin de 
modifier les donnees presentees dans le tableau. 

Modification d'un tableau avec GWT 

La modification des donnees du tableau affichant les todos se realise simplement. Pour Fajout 
et la suppression de todos, des boutons sont mis a disposition afin de declencher les traitements 
correspondants. 

La methode createDel eteWidget cree le bouton pour une ligne du tableau et y associe un 
observateur permettant de supprimer 1' element lorsque le bouton est clique. Dans le code 
suivant, l'interception de l'evenement se realise par l'intermediaire de la classe 
CI i ckLi stener (©) de GWT : 

private Widget createDeleteWidget(final int todolndex) { 
Image deletelmage = new Image("bin_closed.png"); 
deletelmage. addClickl_istener(new CI ickLi stener( ) {<— O 
public void onCl i ck(Widget sender) { 

Serial izableTodo todo = (SerializableTodo) 

currentTodol_ist.getTodos( ) .get(todolndex) ; 
if (Window. conf i rm( "Are you sure you want to delete V" 
+ todo.getDescription( ) + "\"")) { 
currentTodoList.getTodos( ) . remove(todolndex) ; 
del eteTodoOnServer(todo) ; 

} 

} 

}); 

del ete Image. setStyl eName( "sel ect ion -image" ) ; 
return deletelmage; 

} 
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Lorsque l'evenement se produit, le todo est supprime cote serveur en se fondant sur un appel 
AJAX execute a partir de la methode deleteTodoOnServer. Le contenu du tableau est ensuite 
rafraichi grace a la methode pri ntTodoLi st (Q) : 

private void deleteTodoOnServer(SerializableTodo sTodo) { 
AsyncCal 1 back callback = new AsyncCal 1 back( ) { 
public void onSuccess(Object result) { 
pri ntTodoLi st( ) ;<— O 

} 



public void onFai 1 ure(Throwabl e caught) { 
Window. alert( 

"ERROR : the todo could not be deleted " 

+ "on the server. Maybe the server is down."); 

} 

}; 



tuduGwtRemoteService.de! eteTodo(sTodo, cal 1 back) ; 

} 

Pour modifier les lignes du tableau, un simple clic sur le libelle d'un todo rend le champ edita- 
ble (©). Afin que les modifications soient prises en compte, l'application se fonde sur l'utili- 
sation de la touche ENTER (Q) et la perte du focus (Q) pour cette zone d' edition : 

private Widget writeDescription(final int todolndex) { 
final Serial izableTodo todo = (Serial izableTodo) 

currentTodoLi st . getTodos( ) .get (todo Index) ; 
Label todoLabel - new Label (todo. getDescription( )) ; 
todoLabel .addClickListener(new CI i ckLi stener( ) {<— O 
public void onClicktWidget sender) { 

final TextBox editableTodoDescription = new TextBoxO; 
editabl eTodoDescription . setText (todo. get Desc r i pt ion ( ) ) ; 
editabl eTodoDescription 
.add Keyboard Li stener( 

new KeyboardLi stenerAdapter( ) {<— Q 
public void onKeyPress(Widget sender, 

char keyCode, int modifiers) { 
if (keyCode == KeyboardListener.KEY_ENTER) { 
todo.setDescription( 

editabl eTodoDescription .getText( ) ) ; 
updateTodoOnServer(todo) ; 

} 

} 

}); 

editableTodoDescription 

.addFocusListener(new FocusLi stenerAdapter( ) {<— Q 
public void onLostFocus(Widget sender) { 
todo.setDescription( 

editabl eTodoDescription .getText( ) ) ; 
updateTodoOnServer(todo) ; 
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}); 

table. setWidget(todoIndex, 0, editableTodoDescription) ; 



}); 

return todoLabel 



) 



La methode updateTodoOnServer a la responsabilite de realiser l'appel AJAX afin de modifier 
le todo en base de donnees. Une fois cette tache realisee, les donnees relatives aux todos du 
tableau sont rafraichies en se fondant sur la methode pri ntTodoLi st (Q) : 

private void updateTodoOnServer(SerializableTodo sTodo) { 
AsyncCal 1 back callback = new AsyncCal 1 back( ) { 
public void onSuccess(Object result) { 
printTodoList( ) ;<— O 

} 

public void onFai 1 uredhrowabl e caught) { 

Window. alertCERROR : the todo could not be updated " 
+ "on the server. Maybe the server is down."); 

} 

}; 

tuduGwtRemoteServi ce. updateTodo(sTodo , cal 1 back) ; 



Conclusion 

Apres une introduction a AJAX et au Web 2.0, nous nous sommes arretes sur deux grands 
frameworks AJAX, DWR et GWT. Nous avons vu l'apport de ces frameworks pour la mise en 
ceuvre de la technologie AJAX au sein d' applications Web fondees sur Spring. 

DWR permet d'utiliser cote client des Beans Spring provenant d'une application Java EE en 
back-end, le framework ayant la responsabilite du transport des requetes, de la conversion 
d'objets JavaScript en Java et inversement, ainsi que de Futilisation de Beans geres par 
Spring. La combinaison de ces differentes technologies permet de developper des sites Web 
attractifs, radicalement differents de ceux d'avant 2005. C'est la un changement important en 
termes de fonctionnalites et d'utilisabilite, qu'il est important de maitriser. 

GWT va plus loin et adresse la problematique des applications Web riches. Le framework 
permet d'ecrire completement les applications de ce type en Java, un compilateur dedie 
permettant la conversion de la partie client en JavaScript. Cette approche integre la gestion 
multi-navigateur et permet une optimisation transparente des traitements. 

Nous avons vu qu'avec ces outils il n'est plus tres difficile de creer des pages Web utilisant 
AJAX et des applications Web riches. Les difficultes rencontrees se trouvent plutot du cote de 
Futilisation d'AJAX pour DWR en JavaScript et de la connaissance des composants graphi- 
ques disponibles pour GWT. En tout cas, ces deux outils adressent deux aspects distincts : 



Utilisation d'AJAX avec Spring 

Chapitre 9 



ajouter de fonctionnalites AJAX dans des applications classiques pour DWR et mettre en 
ceuvre des applications Web riches pour GWT. 

Dans ce contexte, F utilisation de ces outils offre un gain de productivite important et favorise 
la maintenabilite et l'evolutivite des applications developpees. lis offrent egalement un inte- 
ressant support des principaux navigateurs Web. Ces mecanismes etant simples d'emploi et 
bien outilles, nous ne saurions trop conseiller aux concepteurs de sites Web de F ajouter a leur 
arsenal technique. 
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Les applications d'entreprise sont amenees a communiquer avec des systemes de natures 
diverses, et ce sous des contraintes techniques souvent penibles a gerer. Le cas le plus 
frequent est la communication avec une base de donnees relationnelle pour la recuperation 
et la mise a jour de donnees, sur laquelle vient se greffer la notion de transaction afin de 
gerer Fintegrite des donnees et l'aspect concurrentiel. 

Spring propose un support des plus interessants pour ces deux problematiques, avec F inte- 
gration des solutions les plus courantes d'acces aux bases de donnees relationnelles (JDBC, 
JPA, Hibernate, etc.), ainsi qu'un mecanisme de gestion des transactions generique, portable et 
declaratif. Les chapitres 10 et 1 1 traitent respectivement de ces deux aspects. 

Le chapitre 12 traite du support Spring pour deux standards du monde Java EE : JCA et 
JMS. Si les bases de donnees de donnees relationnelles se retrouvent pratiquement syste- 
matiquement dans les applications d'entreprise, il n'est pas rare qu'elles doivent s'interfa- 
cer avec des systemes completement differents et heterogenes. Dans le monde Java, la 
specification JCA (Java Connector Architecture) normalise les echanges avec ces systemes. 

Spring propose un support JCA afin de simphfier F utilisation parfois complexe de cette 
API. La norme JMS permet quant a elle d'ecrire des applications orientees « message », 
afin de decoupler les composants d'une application ou d'effectuer des traitements asyn- 
chrones. Le support Spring se revele particulierement interessant grace a la simplification 
qu'il apporte mais surtout grace a la possibilite de mettre en ceuvre des observateurs JMS a 
partir de simples objets Java. 

Cette partie nous plonge au cceur du support Spring pour Java EE. Les technologies couver- 
tes etant complexes, chaque chapitre propose une introduction et traite du vocabulaire ainsi 
que des bonnes pratiques pour chacune d'entre elles. 
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La persistance des donnees est generalement une problematique majeure pour les applications 
Java EE, car les donnees manipulees par une application sont souvent d'une importance 
strategique. 

La principale technologie de persistance utilisee est celle des bases de donnees relationnelles. 
Les rares solutions concurrentes, comme les bases de donnees orientees objet, sont peu utilisees, et 
nous ne nous attarderons pas sur elles. 

Les bases de donnees relationnelles permettent de traiter et de stocker de larges volumes de 
donnees, et ce d'une maniere totalement independante du langage de programmation utilise 
pour acceder a ces donnees (Java, PHP, C#, etc.)- Cette ouverture est une des raisons principa- 
les du succes de cette technologie. 

Cela a toutefois un prix pour le programmeur Java, puisque ce dernier est contraint de faire 
cohabiter deux mondes conceptuellement differents, le monde objet et le monde relationnel. 
En consequence, les applications Java s'appuyant sur des bases de donnees relationnelles sont 
tres souvent lourdes a coder, difficiles a faire evoluer et peu performantes. Cela provient 
essentiellement d'une utilisation abusive de JDBC (Java DataBase Connectivity), la technologie 
Java standard de bas niveau pour acceder aux bases de donnees. 

Ce chapitre commence par une introduction aux bonnes pratiques classiques en termes de persis- 
tance des donnees et introduit les concepts fondamentaux generalement admis dans ce domaine. 

Dans un deuxieme temps, nous etudions le principe du support de Spring pour Faeces aux 
donnees, car si Spring propose un support pour differentes technologies, les memes principes 
sont appliques pour chacune d'entre elles. 

Les principes du support Spring seront ensuite appliques au cas de JDBC, puis a un ensemble 
d'outils de mapping objet/relationnel, ou ORM (Object Relational Mapping). Ces outils 
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proposent une couche d' abstraction superieure a JDBC, sur laquelle ils reposent, et permettent 
de combler le fosse entre bases de donnees relationnelles et objets Java. 



Strategies et design patterns classiques 

La persistance des donnees est un sujet aujourd'hui relativement bien theorise. La plupart des 
entreprises utilisent des pratiques et un vocabulaire communs, rassembles sous le nom de 
design patterns, ou modeles de conception. 

Nous allons commencer par presenter cette base commune, qui est un prerequis a la compre- 
hension d'API de plus haut niveau, telles que l'integration de Spring avec des outils d'ORM, 
que nous etudions en fin de chapitre. 

Le design pattern script de transaction 

Le design pattern script de transaction (transaction script) correspond au developpement d'un 
code d'acces a la base de donnees par cas d'utilisation. Dans le domaine de la persistance, il 
s'agit du modele de conception le plus simple. On le retrouve souvent dans les applications 
non decoupees en couches, a l'interieur des servlets ou des controleurs web (par exemple, les 
actions dans Struts). 

Si Ton prend le cas de Spring MVC (ou tout autre framework web MVC), chaque controleur 
correspond a un cas d'utilisation. II y a done une relation 1-1 entre le controleur et le script de 
transaction. C'est pour cette raison que les applications qui utilisent ce modele de conception 
ne sont generalement pas cogues en couches. Le code d'acces a la base de donnees est direc- 
tement inclus dans le controleur. L acces aux donnees est fait en JDBC ou via une fine couche 
d'encapsulation purement technique (par exemple, la gestion de l'ouverture et de la fermeture 
des connexions). 

Les points forts du pattern script de transaction sont les suivants : 

• Grande simplicite d'utilisation. 

• Les acces a la base de donnees peuvent etre optimises au maximum. 

• Plusieurs developpeurs peuvent travailler en parallele sur des cas d'utilisation differents, 
avec une gestion de projet tres simplifiee. 

Ses points faibles sont les suivants : 

• Aucune reutilisation du code : ce motif de conception s'essouffle rapidement des lors que 
l'application grandit un peu (plus de 10-15 tables en base de donnees). 

• La maintenance devient vite un cauchemar, chaque cas d'utilisation ay ant ete developpe de 
maniere procedurale. Changer une table de la base de donnees revient cher. 

En conclusion, ce motif de conception est utile dans certains cas specifiques, ou les acces en 
base de donnees doivent etre optimises au maximum. Cependant, fonder une application 
complete sur cette conception serait une erreur, car les couts d' evolution et de maintenance de 
l'application deviendraient rapidement eleves. 
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Le design pattern DAO 

Les DAO (Data Access Object), ou objets d'acces aux donnees, ont la tache de creer (Create), 
recuperer (Retrieve), mettre a jour (Update) et effacer (Delete) des objets Java, d'oil Fexpres- 
sion associee pattern CRUD (Create, Retrieve, Update, Delete). 

Ce sont des classes utilitaires qui gerent la persistance des objets metier. Nous separons ainsi 
les donnees, stockees dans des JavaBeans, et le traitement de ces donnees. Les DAO ont gene- 
ralement le squelette suivant : 

package tudii.domain.dao; 

import java.util .Collection; 

import tudu. domain. model .Todo; 

/** DAO pour le JavaBean Todo */ 
public interface TodoDAO { 

/** Trouve tous les Todos appartenant a une liste. */ 
public Collection<Todo> getTodosByListId(String listld); 

/** trouve un Todo par son identifiant */ 
public Todo getTodo(String todold); 

/** Cree un Todo. */ 

public void createTodo(Todo todo); 

/** Met a jour un Todo. */ 

public void updateTodo(Todo todo); 

/** Efface un Todo */ 

public void removeTodo(String todold); 

} 

Un DAO est un objet threadsafe, c'est-a-dire qu'il est accessible en simultane par plusieurs 
threads. A F inverse d'un JavaBean, qui contient des donnees specifiques de Faction en cours, 
un DAO ne fait que du traitement. II peut, par consequent, etre commun a plusieurs actions 
paralleles. Pour cette raison, les DAO peuvent etre implementes comme des singletons, avec 
une seule instance partagee par Fensemble des objets de Fapplication. 

Les DAO encapsulent la logique de gestion des donnees, masquant completement la technolo- 
gic sous-jacente. lis peuvent done etre implementes en JDBC ou avec un outil d'ORM. Nous 
verrons par la suite comment Spring facilite Fecriture de DAO dans un cas comme dans Fautre. 

Les points forts des DAO sont les suivants : 

• Reutilisation du code : un DAO peut etre utilise par plusieurs objets metier differents. 

• Simplicite : leur comprehension et leur bonne utilisation ne necessitent qu'un investissement 
leger. 

• Bonne structuration du code : separation de Faeces aux donnees du reste du code. 
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Leurs points faibles sont les suivants : 

• lis sont potentiellement moins performants que du code SQL realise sur mesure pour 
chaque besoin metier. 

• lis sont longs et fastidieux a coder en JDBC. 



Le design pattern modele de domaine et le mapping objet/reiationnel 

Le design pattern modele de domaine (domain model) propose de modeliser le domaine fonc- 
tionnel avec des objets Java, d'ou son nom. II va plus loin que le simple pattern DAO, parce 
qu'il apporte la volonte de modeliser un metier en langage informatique. II represente une 
approche objet, que nous recommandons vivement pour les applications Web de moyenne ou 
grande taille. 

L' etude de cas Tudu Lists est concue suivant ce principe. Le fonctionnel dicte qu'un utilisateur 
possede plusieurs listes de todos et que chacune de ces listes possede a son tour plusieurs todos. 
Les JavaBeans User, TodoList et Todo (dans le package tudu. domain. model) ont ete concus en 
consequence. Ainsi, le JavaBean User possede-t-il en attribut une collection de TodoLists. 
II s'agit done bien d'une modelisation du domaine fonctionnel de l'application en Java. 

Bien entendu, il est primordial de pouvoir enregistrer ces objets en base de donnees. lis sont 
done sauvegardes dans des tables les representant. Le modele de donnees de Tudu Lists est 
explicite pour cela. Lobjet User est sauvegarde dans une table User, possedant en champs les 
attributs du JavaBean. De la meme maniere, les relations entre les JavaBeans, qui sont des 
collections en Java, deviennent des cles etrangeres en base de donnees. 

La persistance de cette couche de domaine peut certes etre codee en JDBC pur, mais nous 
nous rendons vite compte des limitations de ce code artisanal des que nous voulons utiliser 
des jointures complexes entre objets. C'est le cas, par exemple, des relations many-to-many, 
qui necessitent l'utilisation d'une table de jointure intermediaire. Dans Tudu Lists, nous utili- 
sons la table USER_T0D0_LIST pour effectuer la liaison entre les tables USER et T0D0_LIST. En 
effet, un utilisateur possede plusieurs listes, et une liste est possedee par plusieurs utilisateurs. 
Coder manuellement ce type de relation entre tables est fastidieux et peu efficace. 

Le mapping objet/relationnel, ou ORM (Object Relational Mapping), designe Fensemble des 
technologies permettant de faire correspondre un modele objet et une base de donnees rela- 
tionnelle. Comme nous l'avons vu precedemment, cette correspondance est loin d'etre 
evidente. Par exemple, comment modeliser l'heritage ou le polymorphisme, deux notions 
objet qui n'existent pas du tout en base de donnees ? 

Le concept de mapping objet/relationnel autorise done la realisation aisee d'une couche de 
domaine grace a l'utilisation d'outils specialises. C'est pour cette raison qu'il connait un succes 
grandissant depuis plusieurs annees. JPA, Hibernate ou iBATIS sont des exemples de technolo- 
gies de mapping objet/relationnel populaires, que nous etudions ulterieurement dans ce chapitre. 

Les points forts du pattern modele de domaine sont les suivants : 

• Tres bonne evolutivite du code et couts de maintenance reduits. 

• La reutilisation du code est possible en de nombreux points de l'application. 
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Ses points faibles sont les suivants : 

• Necessite de solides competences en programmation orientee objet et en gestion des tran- 
sactions. 

• Pousse a l'utilisation d'un outillage evolue. 

• Necessite une bonne comprehension du fonctionnement du moteur de mapping selectionne. 

• Fonctionne difficilement sur un modele relationnel existant trop eloigne des concepts objets 
(par exemple, avec un schema de base de donnees denormalise). 

En conclusion, l'utilisation d'un modele de domaine devient necessaire des lors qu'une appli- 
cation depasse la taille critique de 10 a 15 tables en base de donnees. Le passage a cette etape 
necessite generalement de bonnes connaissances en technologie objet et un outillage adequat. 
Ces investissements necessaires sont rapidement rentabilises. 



En resume 

Les design patterns simples, tels que le script de transaction et les DAO, sont aujourd'hui 
largement repandus au sein des applications d'entreprise. II s'agit de concepts simples a 
mettre en ceuvre, mais qui doivent etre imperativement maitrises avant de se lancer dans la 
conception d'une application. 

L' apparition au cours des dernieres annees de technologies de mapping objet/relationnel effi- 
caces et bon marche change la donne, puisqu'elles permettent de concevoir aisement des 
couches de domaine completes. 

Nous verrons dans la suite de ce chapitre comment ces technologies, couplees a Spring, redui- 
sent considerablement le code d'une application, tout en ameliorant ses performances, sa 
maintenabilite et sa montee en charge. 



Acces aux donnees avec Spring 

Spring propose un support pour de nombreuses technologies d' acces aux donnees. Malgre la 
diversite de ces technologies, ce support reste homogene dans son utilisation par le developpeur. 

Le support d'acces aux donnees de Spring s'integre parfaitement avec le motif de conception 
DAO. Cela n'est pas une condition sine qua none mais la philosophie du support s'appre- 
hende plus facilement avec la notion de DAO en tete. Le principe de methodes de rappel (call- 
back) est aussi fortement utilise. 

L'idee du support d'acces aux donnees est d'affranchir le developpeur des taches repetitives et 
propices a des erreurs : ouverture/fermeture des connexions, manipulation des API specifiques. 
Le developpeur n'a alors qu'a implementer les methodes de rappel, qui seront appelees par le 
support Spring. II s'agit d'un autre exemple d'inversion de controle, dans lequel le code applicatif 
est appele au sein d'un flot qu'il n'a pas a gerer. Ces methodes de rappel implementent evidem- 
ment des requetes dans la technologie choisie (SQL pour du JDBC, HQL pour Hibernate, etc.). 

Les classes du support implementant le comportement decrit ci-dessus s'appellent des templates. 
II existe des classes de templates pour les differentes technologies supportees par Spring. 



Gestion des donnees 

Partie III 



Le diagramme de la figure 10-1 illustre le principe des methodes de rappel. 



Figure 10-1 

Methodes de rappel 
des templates Spring 



Template 
(code Spring) 



j 1 . Ouverture de la connexion 

i 2. Commencement de la transaction 



i 5. Commit/rollback de la transaction 
i 6. Fermeture de la connexion 



Methodes de rappel 
(code applicatif) 



3. Execution de la requete 



4. Recuperation des donnees 



Dans ce schema de principe, nous constatons que les templates incluent aussi des interactions 
avec la transaction en cours. Nous verrons au chapitre suivant, consacre aux transactions, que 
tout template Spring est capable de s'inserer dans le contexte transactionnel courant. 

Voici un exemple de requete SQL effectuee avec le template JDBC de Spring : 

JdbcTempl ate template = new JdbcTempl ate(dataSource) ; 
int countProperties = template. queryForInt( 
"select count(*) from property" 

); 

Pour celles et ceux ayant utilise l'API JDBC, le contraste est saisissant : pas de gestion de 
ressources (connexion, statement) ni d'exception a gerer et recuperation du resultat immediate 
(sans devoir manipuler plusieurs objets JDBC). Toutes ces problematiques sont gerees par Spring. 
Dans cet exemple, la methode de rappel s'avere etre F execution de la requete SQL, effectuant le 
comptage des proprietes de Tudu Lists. Linitialisation du JdbcTempl ate se fait tres simplement, 
avec un DataSource. Nous verrons Futilisation du JdbcTempl ate plus en detail par la suite. 

Les templates Spring peuvent etre declares dans un contexte Spring et injectes dans des DAO. 
Cela permet un modele totalement POJO (les DAO n'implementent aucune interface techni- 
que ou n'heritent d'aucune classe abstraite specifique). Si ce modele POJO n'est pas une prio- 
rite, Spring propose aussi un ensemble de classes de base de DAO. II existe en fait une classe 
de DAO par template. Les classes de base des DAO contiennent un template qui peut etre 
utilise directement. La classe de DAO pour JDBC s'appelle, par exemple, JdbcDaoSupport et 
contient une propriete JdbcTempl ate. Ce fonctionnement est identique pour les autres technologies 
supportees (Hi bernateDaoSupport et Hi bernateTempl ate, JpaDaoSupport et JpaTempl ate, etc.). 



Gestion des exceptions 

Toute exception provenant d'un DAO doit respecter le principe d' encapsulation propre a ce 
motif de conception. II faut done que les exceptions provenant des DAO soient independantes 
de la technologie sous-jacente. Pour aller dans ce sens, Spring propose deux choses : 

• Une hierarchie de classes d'exception d'acces aux donnees. 
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• L' encapsulation systematique par les templates de toute exception technique dans une des 
classes de cette hierarchie. 

La classe mere des exceptions d'acces aux donnees de Spring s'appelle DataAccessException. 
II s'agit d'une exception non explicite, c'est-a-dire qu'elle ne doit pas etre obligatoirement 
geree via un bloc try/catch. Toute exception lancee par le code sous-jacent (code appele par le 
template) est transformee en une exception fille de DataAccessException, et ce pour toutes les 
technologies utilisees (SQLException pour JDBC, HibernateException pour Hibernate). 

Les representantes de cette hierarchie sont nombreuses. En voici une liste non exhaustive 
(elles sont toutes filles de DataAccessException) : 

• DatalntegrityViol ationException : utilisee lorsqu'une violation de contrainte est detectee 
par la base de donnee (par exemple, contrainte d'unicite non respectee). 

• Data Retrieval Fail ure Except ion : utilisee lorsque des donnees n'ont pu etre recuperees (par 
exemple, tentative de recuperation d'une ligne avec un identifiant qui n'existe pas). Cette 
exception est generalement lancee par des outils d'ORM. 

• ConcurrencyFailureException : utilisee lorsqu'un probleme de concurrence (verrou pessi- 
miste ou optimiste) est rencontre. Cette exception est lancee, par exemple, quand un outil 
d'ORM detecte un probleme d'acces concurrent. 

Les templates Spring lancent systematiquement des DataAccessExceptions qui encapsulent 
des exceptions techniques, mais il est aussi conseille d'en lancer directement a partir d'un 
DAO, F element essentiel etant d'utiliser la classe fille adaptee. 

En respectant ce principe d'encapsulation des exceptions, les couches superieures peuvent 
choisir de gerer les exceptions venant des DAO de facon completement independante de la 
technologie de persistance sous-jacente. 



Support JDBC de Spring 

JdbcTemplate et ses variantes 

La classe centrale du support JDBC de Spring se nomme org. spring- 
framework, jdbc. core. JdbcTemplate. Elle propose une API tres directe pour effectuer toute 
operation en base de donnees, sans se soucier des problematiques telles que la gestion des 
ressources ou des exceptions. Generalement, un JdbcTemplate est injecte dans DAO, qui 
l'utilise ensuite pour effectuer toutes ses operations en base de donnees. 

Un JdbcTemplate ne necessite qu'un DataSource pour etre operationnel. Une fois initialise, le 
JdbcTempl ate est totalement threadsafe, c'est-a-dire qu'il peut etre utilise par plusieurs threads 
en meme temps. II est done possible de creer un seul JdbcTempl ate pour toute une application 
et de l'injecter dans tous les DAO. 

Un JdbcTemplate n'est generalement pas initialise de facon programmatique, mais plutot 
declare dans un contexte Spring : 

<bean id="dataSource" class="..." /> 
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<bean id="jdbcTemplate" 

class="org.springf ramework. jdbc.core. JdbcTempl ate"> 
<property name="dataSource" ref="dataSource" /> 
</bean> 

Le DataSource peut etre de n'importe quelle nature (issu d'un pool de connexions ou d'un 
appel JNDI). Une fois declare dans le contexte Spring, le JdbcTempl ate peut etre injecte dans 
un DAO. 

L' API du JdbcTempl ate est assez simple. Par exemple, pour effectuer une requete d'insertion, 
il suffit d'utiliser la methode update : 

jdbcTempl ate . update ( 

"insert into property (pkey, value) values (?,?)", 
new Object [] {"smtp. user" , "someuser"} 

L'interet du JdbcTempl ate se voit immediatement par la concision qu'il apporte. Cependant, il 
represente l'approche de plus bas niveau du support JDBC de Spring. Nous n'allons pas entrer 
dans les details de son utilisation, mais plutot etudier ses variantes qui apportent chacune leurs 
benefices. 

La premiere variante du JdbcTemplate est le NamedParameterJdbcTemplate. II permet de 
s'affranchir des parametres sous forme de « ? » du JDBC traditionnel au profit de parametres 
clairement nommes. Le code est ainsi auto-documente et plus lisible. De plus, quand le 
nombre de parametres est variable, comme pour un formulaire de recherche comprenant beau- 
coup de champs, F utilisation de parametres nommes est beaucoup plus simple. Tout comme le 
JdbcTempl ate, le NamedParameterJdbcTempl ate est threadsafe une fois initialise. 

Un NamedParameterJdbcTemplate se declare de la facon suivante : 
<bean id="dataSource" class="..." /> 

<bean id="namedParameterJdbcTemplate" class=" 

org.springf ramework. jdbc.core. namedpa ram. NamedParameterJdbcTempl ate 
"> 

<constructor-arg ref="dataSource" /> 
</bean> 

A la difference du JdbcTemplate, le NamedParameterJdbcTemplate doit se voir injecter le 
DataSource dans le constructeur. Voici la meme operation d'insertion que precedemment : 

Map<String, Object> parametres = new HashMap<String, Object>();<— Q 
parametres .put ( "key" , "smtp. user" ) ;<— Q 
parametres .putt "val ue" , "someuser" ) ; 
named Parameter JdbcTempl ate. update ( 

"insert into property (pkey, value) values ( : key , : val ue) " ,<— Q 

parametres 

); 

Les parametres vont etre contenus dans une Map (©). Au repere Q. nous definissons le para- 
metre key ; le parametre value est a la ligne suivante. La requete n'utilise plus des points 
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d' interrogation pour definir les parametres, mais les noms de ces parametres, precedes de 
« : » (©). Cette syntaxe, bien que moins concise que la precedente, est plus lisible et gere 
mieux les cas complexes. 

Qu'en est-il des requetes de selection de donnees ? Les deux JdbcTempl ates precedemment 
decrits permettent de gerer facilement des requetes retournant des resultats simples, comme 
pour un comptage : 

int countProperties = tempi ate. queryForInt( 
"select count(*) from property" 

II est aussi possible de recuperer un ensemble d'enregistrements. On recupere alors une Li st 
de Map, chaque Map comportant une entree pour chacun des champs. Voici un exemple de la 
recuperation des proprietes de Tudu Lists : 

List<Map<String,Object>> resultats = namedParameterJdbcTemplate.*» 
queryForl_ist( 

"select pkey, value from property", 
new HashMap<String,Object>( ) 
>:<-© 

for(Map<String,Object> row : resultats) {<— Q 
Property property = new PropertyO; 
property . set Key ( (String) row. get ( "pkey" ) ) ;<— Q 
property . setVal ue( (String) row. get ( "val ue" ) ) ;<— Q 
(...) 

} 

Nous appelons la methode queryForList avec, en parametres, la requete et la Map de parame- 
tres nommes (Q). La requete n'ayant pas de parametres, nous passons directement une Map 
vide. Le resultats etant une liste de Map, nous iterons sur chacun des elements (Q). Suivant le 
principe du modele de domaine, nous creons un objet Property et lui assignons le resultat de 
la requete. 

La recuperation des donnees avec un JdbcTempl ate (ou un NamedParameterJdbcTemplate) 
represente encore une grande avancee par rapport a du JDBC simple. Cependant, si nous 
suivons le principe du modele de domaine, la sequence de transformation d'une Map en un 
objet de domaine risque d'etre souvent dupliquee dans le code. C'est la raison pour laquelle il 
est possible d'utiliser avec une requete de selection un RowMapper, dont le but est de transformer 
chaque Resul tSet JDBC en un objet. 

L'interface d'un RowMapper est la suivante : 

public interface RowMapper { 

Object mapRow(ResultSet rs, int rowNum) throws SQLException; 

II est aise de definir un RowMapper pour la classe Property de Tudu List : 

import org. springf ramework. jdbc. core. RowMapper; 
import tudu. domain. model .Property; 
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public class PropertyRowMapper implements RowMapper { 

public Object mapRow(ResultSet rs, int rowNum) 
throws SQLException { 
Property property = new PropertyO; 
property . set Key ( rs . getStri ng( "pkey" ) ) ; 
property . setVal ue( rs .getString( "val ue" ) ) ; 
return property; 

} 

} 

Une instance de cette classe peut ensuite etre passee a une requete a la methode query : 

Li st<Property> resultats = namedParameterJdbcTemplate. query ( 
"select pkey, value from property", 
new HashMap( ) , 
new PropertyRowMapper( ) 

); 

Property property = resultats. get(O) ; 
(...) 

Une nouvelle instance de PropertyRowMapper est creee pour chaque requete, mais il est impor- 
tant de noter qu'une unique instance pourrait etre reutilisee pour chaque appel (la classe ne 
contenant aucune propriete est done threadsafe). L'approche utilisant un RowMapper permet 
une bien meilleure reutilisabilite du code transformant une structure de donnees orientee base 
de donnees en un objet de domaine. Bien que le RowMapper ne fonctionne que pour les operations 
de lecture, son utilisation s'approche d'une solution d'ORM. 

Un probleme subsiste dans l'exemple precedent : il tire profit des generiques de Java 5, mais 
pas d'une facon totalement sure. C'est pourquoi la classe ParameterizedRowMapper peut etre 
typee. Elle permet alors de beneficier des verifications faites a la compilation, assurant 
qu' aucune ClassCastException ne sera lancee a l'execution. Voici 1' implementation du 
ParameterizedRowMapper pour la classe Property : 

import org.springf ramework. jdbc.core.simpl e. ParameterizedRowMapper 
import tudu. domain. model .Property; 

public class PropertyParameterizedRowMapper implements 
Parameter!' zed RowMappeK Property > { 

public Property mapRow(ResultSet rs, int rowNum) 
throws SQLException { 
Property property = new PropertyO; 
property .setKey( rs .getString( "pkey" ) ) ; 
property .setVal ue( rs . getString( "val ue" ) ) ; 
return property; 

} 



} 
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L'utilisation de ce nouveau RowMapper est identique a la precedente, mais elle ne semble pas 
vraiment corriger le probleme de verification des types. En effet, un environnement de deve- 
loppement comme Eclipse affiche des avertissements (warning) pour le code recuperant la 
liste de Property. Cela est du au fait que le NamedParameterJdbcTempl ate ne tire pas pleinement 
parti des generiques de Java 5. 

Cela nous mene directement au SimpleJdbcTemplate, qui propose non seulement un support 
pour les nouveautes syntaxiques de Java 5, mais aussi une API plus pragmatique que ses 
confreres templates. Concernant la syntaxe, Simpl eJdbcTempl ate exploite les generiques et les 
methodes a arguments variables. L'utilisation des generiques permet d'eviter le transtypage, 
mais aussi de verifier son code des la compilation. L'utilisation des methodes a arguments 
variables permet de ne pas creer de tableaux pour le passage de parametres. II s'agit la certes 
principalement d'un confort de programmation, mais qui est grandement appreciable. Le 
Simpl eJdbcTempl ate est lui aussi threadsafe une fois initialise. 

La declaration d'un Simpl eJdbcTempl ate se fait de la maniere suivante : 

<bean i d=" simpl eJdbcTempl ate" 

cl ass-"org.springf ramework. jdbc. co re. simple. Simpl eJdbcTempl ate"> 
<constructor-arg ref="dataSource" /> 
</bean> 

Le SimpleJdbcTemplate doit aussi se voir passer le DataSource dans le constructeur. Pour une 
methode de selection de donnees, le fonctionnement du Simpl eJdbcTempl ate est tres proche de 
celui de ses confreres : 

List<Property> resultats = SimpleJdbcTemplate. query( 
"select pkey, value from property", 
new PropertyParameterizedRowMapper( ) 

); 

Property property = resultats. get(O) ; 
(...) 

II y a cependant deux differences importantes dans le code precedent par rapport au code du 
NamedParameterJdbcTempl ate. La premiere est que le Simpl eJdbcTempl ate peut ne pas recevoir 
d'argument destine a la requete. Cela evite de creer une Map vide. La deuxieme difference est 
que ce code est completement sur au niveau du typage, grace notamment a l'utilisation du 
ParameterizedRowMapper dedie a la classe Property. 

Si nous voulons ajouter un parametre a la requete pour filtrer : 

List<Property> resultats = SimpleJdbcTemplate. query( 
"select pkey, value from property where pkey = ?", 
new PropertyParameterizedRowMapper( ) , 
"smtp.host" 



); 

Property property = resultats. isEmptyO ? null 
Si nous voulons rajouter un autre parametre de filtre : 



resultats. get(O) ; 



List<Property> resultats = SimpleJdbcTemplate. query( 

"select pkey, value from property where pkey = ? or pkey = ?", 



Gestion des donnees 

Partie III 

new Property Pa rameteri zedRowMapper( ) , 
"smtp.host" , "smtp. user" 

); 

Property property = resul tats . i sEmpty ( ) ? null : resultats.get(O) ; 

Les methodes a arguments variables nous permettent done d'ajouter autant de parametres que 
nous voulons, sans devoir passer par la creation un peu penible d'un tableau. 

II est aussi possible de passer autant de parametres que Ton veut pour effectuer une insertion : 

simpl eJdbcTempl ate . update ( 

"insert into property (pkey, value) values (?,?)", 
"smtp. user" , "someuser" 

); 



Le support JDBC dans Spring 3.0 

Depuis Spring 3.0, la plupart de I'API du support JDBC tire pleinement partie des generiques. Ainsi, il est 
possible d'utiliser directement un RowMapper et de beneficier du typage pour I'objet retourne. Le JdbcTem- 
pl ate utilise aussi les generiques et les methodes a arguments, mais son API reste toujours tres complete 
et done un peu complexe, justifiant toujours I'utilisation du Simpl eJdbcTempl ate, au final plus simple. 



Le Simpl eJdbcTempl ate est done la classe a privilegier pour la plupart des usages. II supporte 
en effet, d'une part, les parametres nommes et permet, d'autre part, des facilites syntaxiques. 
Le Simpl eJdbcTempl ate ne permet cependant pas d'effectuer des requetes tres specifiques, 
necessitant, par exemple, de preciser les types SQL a utiliser. II est done possible 
d'acceder a F equivalent d'un NamedParameterJdbcTempl ate via la methode getNamedPara- 
meterJdbcOperations. II est aussi possible d'acceder a l'equivalent d'un JdbcTempl ate via la 
methode getJdbcOperations. Cela est rendu possible par le fait que le Simpl eJdbcTempl ate 
utilise en interne un NamedParameterJdbcTempl ate. 

Classe de DAO pour JDBC 

Comme decrit dans les principes du support d'acces aux donnees de Spring, il existe des 
classes de support pour les DAO fondes sur JDBC. II existe en fait une classe de support 
pour chacun des types de templates (JdbcTempl ate, NamedParameterJdbcTempl ate et Simpl e- 
JdbcTempl ate). Puisque nous preconisons d'utiliser le Simpl eJdbcTempl ate, il est normal que 
nous preconisions d'utiliser sa classe de support : Simpl eJdbcDaoSupport. Pour beneficier de 
ce support, un DAO doit heriter de cette classe : 

package tudu. domain. dao.jdbc; 

import org. spr i ngf ramewo r k. jdbc. co re. simpl e. Simpl eJdbcDaoSupport; 
import tudu.domain.dao. Property DAO; 

public class PropertyDAOJdbc extends Simpl eJdbcDaoSupport 
implements PropertyDAO { 

(...) 



) 
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II est ensuite possible d'acceder au SimpleJdbcTemplate via la methode getSimpl eJdbc- 
Template. Voici, par exemple, 1' implementation de la sauvegarde d'une propriete dans Tudu 
Lists : 

public class PropertyDAOJdbc extends Simpl eJdbcDaoSupport 
implements PropertyDAO { 

public void saveProperty( Property property) { 
getSimpl eJdbcTempl ate( ) . update ( 

"insert into property (pkey, value) values (?,?)", 
property . get Key ( ) .property .getVal ue( ) 

); 

} 

(...) 

} 

Le DAO doit etre declare comme tout objet Spring, d'une part, pour etre initialise correcte- 
ment (avec le DataSource) et, d'autre part, pour pouvoir etre injecte dans d'autres Beans 
l'utilisant. Voici cette declaration : 

<bean id="propertyDAOJdbc" 

class-"tudu.domain.dao. jdbc. PropertyDAOJdbc "> 
<property name="dataSource" ref="dataSource" /> 
</bean> 



Configuration d'une DataSource 

Dans Java EE, une DataSource represente une abstraction pour se connecter a une base de 
donnees. Spring nous aide non seulement dans la creation et la configuration d'une 
DataSource, mais aussi en nous offrant des implementations de DataSource. 

Une DataSource est configuree comme n'importe quel autre objet Spring. II existe de 
nombreuses implementations de DataSource, la plupart proposant la notion de pool de 
connexions. Un pool de connexions est un ensemble de connexions a une base de donnees 
laissees a la disposition d'une ou plusieurs applications. 

Derriere la methode getConnection de DataSource, le pool de connexions peut cacher une 
mecanique assez complexe pour gerer au mieux ses connexions. Generalement, un pool de 
connexions cree un nombre initial de connexions au demarrage d'une application et fait 
augmenter ou diminuer ce nombre selon la charge de 1' application. L'idee est d'optimiser 
au mieux ces connexions : reutiliser le plus possible les connexions d'une requete utilisa- 
teur a une autre et eviter que la base de donnees ne s'ecroule en ouvrant trop de 
connexions. 

Selon les applications (e-commerce, intranet, etc.), il peut etre possible de gerer une centaine 
d'utilisateurs avec trois ou quatre connexions base de donnees. Le projet Commons DBCP de 
la communaute Apache (http://commons.apache.org/dbcp/) propose une implementation de 
pool de connexions, notamment utilisee dans le conteneur Web Tomcat. 
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II est possible de configurer un pool de connexions avec DBCP dans un contexte Spring : 

<bean id="mysql DataSource" 

cl a ss=" org. apache. commons. dbcp.BasicDataSource" 
des troy- met hod="cl ose"> 

<property name="dri verCl assName" val ue="com.mysql . jdbc.Driver"/> 

<property name="url " val ue="jdbc:mysql ://localhost:3306/tudu"/> 

<property name="username" val ue-"tudu"/> 

<property name="password" val ue="mdp4tudu"/> 

<property name="maxActive" value="50"/> 

<property name="maxldl e" value="30"/> 
</bean> 

<!-- utilisation dans un DAO --> 
<bean id="propertyDAOJdbc" 

cl ass-" tudu.domain.dao. jdbc. Property DA0Jdbc"> 
<property name="dataSource" ref="mysql DataSource" /> 
</bean> 

Cet exemple montre un pool de connexions utilisant une base de donnees MySQL. Des attri- 
buts permettent la connexion a la base de donnees (driver, url, utilisateur et mot de passe), 
tandis que d'autres influent sur la gestion des connexions. L'attribut maxActive precise le 
nombre maximal de connexions que ce pool peut ouvrir. Si plus de cinquante connexions sont 
necessaires en meme temps, les demandes sont mises en attente jusqu'a ce que des 
connexions se liberent. Le parametre maxldl e precise le nombre maximal de connexions inac- 
tives dans le pool. Ce parametre permet de rendre des connexions a la base de donnees en cas 
de baisse de charge de F application. Un pool Commons DBCP peut etre configure tres 
finement ; il est conseille de consulter la documentation officielle pour connaitre toutes les 
options. 

Une DataSource implementant un comportement de pool de connexions peut etre declaree de 
facon autonome dans une application Spring, en utilisant, par exemple, Commons DBCP. II 
est aussi possible de declarer un pool de connexions a partir du serveur d' applications. Les 
raisons pour cela peuvent etre diverses : utilisation d'une implementation de pool specifique 
au serveur ; rapport privilegie (notamment de securite) entre le serveur d' applications et le 
serveur base de donnees; partage de la DataSource entre plusieurs applications... La 
DataSource peut alors etre recuperee par JNDI. 

Recuperer un objet de l'arbre JNDI dans Spring se fait via l'espace de nom jee et la balise 
jndi -1 ookup : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. spri ngframework.org/schema/beans" 

xml ns :xsi="http: //www.w3. org/2001 /XMLSchema-i nstance" 

xmlns: jee=" http://www.spr i ngframework.org/schema /jee" 

xsi : schemaLocati on=" 
http: //www. springframework.org/schema/beans 
http: //www. spri ngf ramework.org/schema/beans/spring-beans .xsd 
http: //www. springframework.org/schema/jee 
http: //www. springframework.org/schema/jee/spring- jee. xsd" > 
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<jee: jndi -1 ookup id="dataSource" 
jndi -name=" jdbc/TuduDataSource"/> 

<!-- utilisation dans un DAO --> 
<bean id="propertyDAOJdbc" 

class-"tudu.domain.dao. jdbc. PropertyDAOJdbc"> 
<property name="dataSource" ref="dataSource" /> 
</bean> 

</beans> 

Le look-up JNDI de Spring permet de s'inserer tres facilement dans un contexte Java EE. 

Spring propose deux implementations de DataSource (toutes deux se trouvent dans le package 
org.springf ramewor k.jdbc.dat asource) : 

• DriverManagerDataSource : ouvre une nouvelle connexion a la base de donnees chaque fois 
qu'une connexion est demandee. 

• SingleConnectionDataSource : ouvre une connexion a sa creation et Futilise chaque fois 
qu'une connexion est demandee. 

Ces implementations ne sont pas destinees a etre utilisees pour une application en production, 
mais plutot a des fins de developpement. SingleConnectionDatasource est particulierement 
adaptee aux tests unitaires qui sont generalement lances les uns a la suite des autres. Elle est 
utilisee pour les tests unitaires des Tudu Lists : 

<bean id="dataSource" 
cl ass=" 

org.springf ramewor k.jdbc.dat asource. Si ngleConnectionDataSource"> 
<property name="dri verCl assName" val ue="org. hsql db. jdbcDri ver"/> 
<property name="url" value-"jdbc:hsqldb:mem:tudu-test"/> 
<property name="username" value-"sa"/> 
<property name="password" value=""/> 
<property name="suppressCl ose" val ue="true" /> 
</bean> 

L'attribut suppressCl ose permet de supprimer la fermeture effective de la connexion lorsqu'on 
appelle la methode cl ose dessus. Cela permet de reutiliser la connexion. Dans une application 
Spring (dans laquelle toutes les connexions sont gerees par Spring), la methode close est 
appelee par du code Spring. Appeler cette methode sur une connexion geree par un pool 
revient a rendre la connexion au pool. Pour une SingleConnectionDataSource avec 
suppressCl ose a true, l'appel de cl ose sur la connexion n'a aucun effet. 

En resume 

Spring propose un support tres interessant pour les applications utilisant directement du SQL, 
car il permet de fortement simplifier et fiabiliser le code JDBC. Ce support passe par un 
ensemble de templates (JdbcTemplate, NamedParameter et Simpl eJdbcTempl ate) et leur classe 
de DAO respective. Nous preconisons d'utiliser le support fonde sur le Simpl eJdbcTempl ate, 
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qui propose une API plus simple car se focalisant sur les cas les plus courants et qui tire parti 
des nouveautes syntaxiques de Java 5. 

Spring propose aussi un support pour la gestion des DataSources, avec evidemment la configu- 
ration de ceux-ci dans le conteneur leger (directement ou via JNDI). Spring propose aussi 
deux implementations de DataSources adaptees au developpement et aux tests. 

L' utilisation du support JDBC de Spring est adaptee au ref adoring d' applications basees tota- 
lement sur JDBC ou pour gerer tres finement les acces a la base de donnees (pour profiter, par 
exemple, de certaines fonctionnalites de la base de donnees ou pour des traitements batch). 
Cependant, pour la plupart des applications, les solutions d'ORM sont une solution plus que 
conseillee. 

Support ORM de Spring 

Historiquement, le marche de l'ORM a vu le jour en 1994 avec Fapparition de TopLink, un 
framework alors revolutionnaire developpe par la societe The Object People (le « TOP » de 
TopLink). Au fil du temps, un grand nombre de solutions d'ORM sont apparues sur le marche, 
certaines standardises (EJB, JDO, JPA), d'autres Open Source (Hibernate, iBATIS), dans un 
foisonnement creatif qui, au final, a plutot nui a leur adoption. 

Les sections qui suivent presentent les solutions d'ORM qui nous paraissent les plus pertinen- 
tes et les mieux adoptees a ce jour, ainsi que le support qu'offre Spring pour chacune d'entre 
elles. 

Le standard JPA 

JPA (Java Persistence API) est le standard de persistance pour Java. Developpe au sein du Java 
Community Process, il fait partie de la Java Specification Request 220 (JSR 220), intitulee 
Enterprise JavaBeans 3.0. JPA represente la partie persistance des EJB 3.0 (la JSR 220 
contient notamment le modele de programmation pour les Beans session et les Beans orientes 
message, les regies de deploiement, etc., en plus de la partie persistance). C'est pour pouvoir 
utiliser la partie persistance des EJB en dehors d'un conteneur EJB que cette JSR a ete rendue 
modulaire. 

Cette modularite se repercute sur les produits EJB 3.0 (c'est-a-dire les implementations de la 
JSR 220) : certains d'entre eux implemented la totalite de la specification et d'autres la seule 
partie JPA. 

Spring ne proposant pas directement de support pour les EJB 3.0, nous nous interesserons 
dans cette section aux principes de JPA et a son integration dans Spring. 

JPA propose un modele de persistance oriente POJO, directement inspire d' Hibernate, 
TopLink et JDO (Java Data Objects), le precedent standard de persistance de Java. JPA utilise 
fortement les annotations, notamment pour la definition du mapping objet/relationnel. 
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Commencons par un rapide tour d'horizon de 1' API JPA : 

• javax. persistence. Persistence : classe de demarrage permettant d'acceder au contexte de 
persistance JPA. En utilisant Spring, cette classe n'a pas a etre manipulee. 

• javax. persistence. EntityManagerFactory : cette classe represente une unite de persistance, 
c'est-a-dire un ensemble de classes gerees par JPA. C'est l'equivalent de la SessionFactory 
d'Hibernate. Une EntityManagerFactory est threadsafe, se manipule generalement sous 
forme d'un singleton et permet la creation d'instances d'EntityManager. 

• javax. persistence. EntityManager : cette classe permet d'effectuer des operations sur des 
objets persistants. II s'agit de l'equivalent de la Sessi on Hibernate. Un Enti tyManager repre- 
sente une unite de travail pour l'acces aux donnees et n'est done pas threadsafe. 

La configuration JPA se place generalement dans un fichier appele persistence. xml. On y 
trouve systematiquement la liste des classes annotees (ou un lien vers un fichier definissant le 
mapping), mais aussi des parametres lies a 1' implementation JPA utilisee, voire la definition 
de la DataSource a utiliser. C'est a partir de ce fichier de configuration qu'une (ou plusieurs) 
EntityManagerFactory va etre creee. 

Les deux problematiques de F utilisation de JPA consistent a creer et configurer 
1' EntityManagerFactory puis a gerer le cycle de vie des EntityManager. L'environnement de 
1' application JPA conditionne fortement ces deux problematiques ; Spring offre cependant 
une grande souplesse et une portabilite maximale. 

Creer une EntityManagerFactory 

La premiere facon de creer une EntityManagerFactory avec Spring consiste a utiliser le prin- 
cipe de demarrage par defaut de JPA. Cela se fait en utilisant un Local EntityMana- 
gerFactoryBean : 

<bean id-" enti tyManager Factory" 
cl ass-"org.springf ramework. orm. jpa . Local Enti tyManagerFactoryBean"> 
<property name="persi stenceUnitName" val ue="myPersi stenceUnit"/> 
</bean> 

Le principe de demarrage par defaut consiste a regarder toutes les entrees de META-INF/ 
persistence. xml se trouvant dans le classpath. C'est ce que fait le Local Enti ty- 
ManagerFactoryBean. Le fichier persistence. xml doit done contenir toutes les informations 
necessaires a la configuration, notamment la connexion a la base de donnees. Cette solution 
simpliste n'est a utiliser que dans des environnements de tests ou a des fins de prototypage. 

La deuxieme facon de creer une EntityManagerFactory avec Spring consiste a la recuperer par 
un appel JNDI. Cela sous entend que la EntityManagerFactory a ete creee par le serveur 
d' applications et mis ensuite a disposition dans le contexte JNDI. Voici un exemple de cet 
appel : 

<jee: jndi -lookup id="entityManagerFactory" 
jndi -name=" persistence/my Persi stenceLIni t"/> 



Gestion des donnees 

Partie III 



Dans un scenario comme celui-ci, Spring sert generalement a injecter la EntityManagerFactory 
dans des Beans et a demarquer les transactions via un JtaTransactionManager (la transaction 
JTA etant fournie par le gestionnaire de transactions du serveur d' applications). 

La troisieme et derniere facon de creer une EntityManagerFactory avec Spring consiste a utili- 
ser un Local Contai nerEnti tyManagerFactoryBean. Spring agit alors comme un serveur d'appli- 
cations et definit completement 1' EntityManagerFactory. L'avantage de cette solution est sa 
grande souplesse, sa parfaite integration avec Spring et sa portabilite. Son principal inconve- 
nient est son autonomie : il est difficile de partager 1'EntityManagerFactory avec d'autres 
applications, a moins qu'elles utilisent le meme contexte Spring : 

<bean id="enti tyManager Factory" cl ass="org.springf ramework.orm. jpa . Local - 
Conta i ner Entity Manager Factory Bean" > 

<property name="dataSource" ref="dataSource"/><— Q 

<property name=" jpaVendorAdapter" ref=" jpaVendorAdapter"/><— Q 

<property name="persistenceXml Location" 
val ue="tudu/conf7persistence.xml "/><— Q 

<property name=" jpaProperti es" ref=" jpaProperti es" /><— Q 
</bean> 

Le Local Contai nerEnti tyManagerFactoryBean necessite un ensemble de parametres pour fonc- 
tionner correctement. Une DataSource doit lui etre injectee, ce qui est plus souple que de definir 
la connexion a la base de donnees dans persistence. xml (0). 

Le JpaVendorAdapter est une notion propre a Spring ; il permet de brancher differentes imple- 
mentations de JPA (Q). C'est le JpaVendorAdapter qui fournit la configuration exacte de 
F implementation JPA. Nous verrons comment configurer l'adaptateur Hibernate par la suite. 
II faut preciser le fichier de configuration JPA (T equivalent du fichier META- INF/persi stence.xml), 
qui ne va contenir au final que les instructions de mapping (©). Ce fichier peut porter n'importe 
quel nom et se trouver dans n'importe quel repertoire. II faut cependant eviter META- INF/ 
persistence. xml, car cela pourrait interferer avec le comportement par defaut d'un serveur 
d' applications, qui creerait les unites de persistance correspondantes, en plus de Spring. 

Voici le contenu du fichier tudu/conf/persistence.xml (nous n'utilisons que la classe 
Property pour des raisons de simplicite) : 

<?xml version="1.0" encoding="UTF-8"?> 
persistence 

xml ns="http: //java . sun. com/xml /ns/persi stence" 

xml ns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 

xsi : schema Location=" http://java.sun. com/xml /ns/persi stence 

http: //java . sun . com/xml /ns/persi stence/persistence_l_0.xsd" 

version="l .0"> 

<persi stence -unit name="defaul t" 

transact!' on- type-" RES0URCE_L0CAL"> 

<cl as s>tudu. domain .model . Property </cl ass> 

</persi stence- unit> 
</persistence> 
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Ce fichier ne contient plus que la declaration des classes de domaine, tous les autres para- 
metres de configuration etant geres par Spring, notamment via la propriete jpaProperti es (Q). 
Ces parametres sont exploites par F implementation JPA. Voici une definition possible du 
Bean jpaProperti es si Hibernate est utilise : 

<util properties id="jpaProperties"> 

<prop key=" hi be mate, cache. provider_cl ass "> 

o rg. hibernate. cache. NoCache Provider 
</prop> 

<prop key="hibernate. cache. use_query_cache">f al se</prop> 
<prop key=" hibernate. cache. use_second_level_cache">false</prop> 
</uti 1 :properties> 

A des fins de simplicite, nous desactivons le cache de second niveau d'Hibemate. 
Le listing suivant montre la classe Property, notre classe d'entite : 
package tudu. domain. model ; 

import javax. persistence. Column; 
import javax. persistence. Entity; 
import javax. persistence. Id; 
import javax. persistence. Table; 

©Entity 

@Tabl e(name=" property " ) 
public class Property { 

@Id 

@Col umn(name="pkey" ) 
private String key; 

@Col umn(name="val ue" ) 
private String value; 

/* getter / setter */ 
(...) 

} 

Le mapping utilisant les annotations standards JPA, nous ne nous attarderons pas sur ce sujet. 
Definir un adaptateur JPA 

L'adaptateur JPA (JpaVendorAdapter) est une notion propre a Spring qui permet de definir la 
configuration de 1' implementation JPA. Cette configuration etant geree par un Bean distinct, 
1'EntityManagerFactory est completement independante de 1' implementation JPA finale. 

Spring 2.5 propose des adaptateurs pour les produits suivants : 

• EclipseLink : une implementation de JPA, mais aussi d' autres standards (Java XML 
Binding, Service Data Objects), sous l'egide de la fondation Eclipse. EclipseLink est fonde 
sur le code de TopLink et a ete choisi pour etre 1' implementation de reference de JPA 2.0. 
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• Hibernate : on ne presente plus Hibernate, qui est sans conteste l'outil d'ORM le plus popu- 
late du monde Java. II offre bien evidemment une implementation JPA, utilisee notamment 
par le serveur d' applications JBoss. 

• OpenJPA : une implementation JPA sous l'egide de la fondation Apache. OpenJPA s'appuie 
sur Kodo (une implementation JDO), dont le code a ete donne en 2006 par BEA. OpenJPA 
est integre notamment au serveur d' applications Geronimo. 

• TopLink Essentials : F implementation de reference de JPA 1.0. II s'agit d'une version 
limitee du produit TopLink. 

Nous allons utiliser Fadaptateur Hibernate pour illustrer la configuration de la persistance de 
Tudu Lists. L'adaptateur se configure comme tout Bean Spring : 

<bean id="jpaVendorAdapter" class-" 
org.springf ramework.orm. j pa. vendor. Hi be mate JpaVendorAdapter "><— © 

<property name="showSql " val ue="fal se" /><— Q 

<property name="generateDdl " value="true" /><— Q 

<property name="database" value="HSQL" /><— Q 
</bean> 

L'adaptateur est de type HibernateJpaVendorAdapter, classe se trouvant dans le package 
org.springframework.orm. j pa. vendor (Q). L'adaptateur dispose d'un ensemble de proprietes 
que Ton peut parameter. Nous pouvons, par exemple, demander au produit d'afficher dans la 
console les requetes SQL generees (nous desactivons cette fonctionnalite au repere Q). 

Au repere Q. nous indiquons que nous voulons que les tables soient creees ou mises a jour au 
demarrage de 1'EntityManagerFactory. Cette fonctionnalite est utile dans le cadre du develop- 
pement ou des tests unitaires. Enfin, nous indiquons a l'adaptateur la base de donnees utilisee 
(©)■ Cette indication lui permet de determiner le dialecte Hibernate a utiliser. 

L ensemble des reglages d'un adaptateur JPA Spring est disponible dans la documentation de 
reference, et nous vous invitons a la consulter. 

Implementer un DAO 100 % JPA 

II est possible d'implementer des DAO totalement JPA, c'est-a-dire sans reference a Spring, 
meme si ces DAO sont configures par Spring. On colle ainsi completement au standard, laissant 
la possibilite a ces DAO d'etre geres par un conteneur EJB 3.0 par la suite. 

Voici le DAO 100 % JPA pour la gestion des proprietes de Tudu Lists : 
public class PropertyDAOJpa implements PropertyDAO { 

private EntityManager em; 

©PersistenceContext 

public void setEntityManager(EntityManager em) { 
this. em = em; 

} 

public Property getProperty(String key) { 
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return this. em. find(Property. class, key); 

} 

public void updateProperty( Property property) { 
this. em. merge (property) ; 

} 

public void saveProperty(Property property) { 
this. em. persist (property) ; 

} 

} 

L' annotation ©PersistenceContext permet d'indiquer au conteneur (Spring ou un conteneur 
EJB 3.0) d'injecter 1'EntityManager. Spring est capable d'interpreter cette annotation et 
d'injecter un EntityManager au DAO. 

Comme precise plus haut, un EntityManager n'est pas threadsafe ; il est generalement utilise 
pour une unite de travail de persistance, c'est-a-dire au sein d'un meme thread. Or le DAO est 
un singleton, partage par tous les threads de 1' application. Spring injecte done un proxy, 
charge de retourner un EntityManager pour chaque thread. C'est completement transparent 
pour le developpeur, Spring se chargeant de ce travail complexe. 

Cependant, pour que cela fonctionne, il faut preciser a Spring d' analyser les annotations JPA, 
en utilisant un PersistenceAnnotationBeanPostProcessor : 

<bean class-" 

org. springf ramework.orm. j pa. support. 
Persi stenceAnnotati onBean Post Processor "/> 

<bean id=" property DAO" class="tudu.domain.dao. jpa. PropertyDAOJpa"/> 

Grace a ce BeanPostProcessor, tous les Beans portant Fannotation @PersistenceContext se 
verront injecter 1'EntityManager (lui-meme cree a partir de 1'EntityManagerFactory). 

Spring propose egalement un support permettant a des DAO 100 % JPA de ne lancer que des 
DataAccessExceptions (la hierarchie d'exceptions d'acces aux donnees de Spring). On peut 
done conserver facilement une politique de gestion des exceptions conforme a la philosophie 
Spring, meme si Spring n'est pas directement utilise dans la couche DAO. Cela passe evidemment 
par une decoration des DAO. 

Les DAO doivent se voir apposer Fannotation ©Repository dans un premier temps, et un 
Persi stenceExceptionTranslationPostProcessor doit etre declare dans le contexte Spring. 
Voici le DAO avec Fannotation : 

(...) 

import org. springf ramework. stereotype . Repository; 
©Repository 

public class PropertyDAOJpa implements PropertyDAO { 
(...) 

} 
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Et voici la declaration du PersistenceExcepti onTransl at ion Post Processor : 

<bean class=" 

org. springf ramework.dao. annotation. 
Persi stence Except i onTransl ati onPostProcessor"/> 

Grace a ces deux operations, les DAO sont decores (a l'aide de la POA) de maniere a ce que 
chaque exception JPA soit transformee en exception d'acces aux donnees Spring. 

JpaTemplate et classe de DAO 

En accord avec son principe de support d'acces aux donnees, Spring propose une classe 
de template pour JPA (JpaTemplate) et une classe de base pour des DAO fondes sur JPA 
(JpaDaoSupport). 

Generalement, un JpaTemplate est injecte dans un DAO. Voici comment definir un 
JpaTempl ate et l'injecter dans un DAO : 

| <bean id-" jpaTempl ate" 

cl ass="org.springframework.orm. j pa. JpaTempl ate" > 
<property name="enti tyManager Factory" 
ref="entityManagerFactory" /> 
</bean> 

<bean id-"propertyDAO" 

cl ass="tudu.domain.dao. jpa . Property DAO JpaTempl ate"> 
<property name=" JpaTempl ate" ref=" jpaTempl ate" /> 
</bean> 

L'interface de JpaTemplate est tres proche de celle de 1'EntityManager ; elle offre cependant 
quelques raccourcis. Cela fait que F implementation du DAO utilisant le JpaTemplate ressemble 
fortement a celle du DAO 100 % JPA : 

public class PropertyDAOJpaTempl ate implements PropertyDAO { 

private JpaTemplate JpaTemplate; 

public Property getProperty(String key) { 

return jpaTempl ate. find (Property .cl ass , key) ; 

} 

public void saveProperty ( Property property) { 
jpaTempl ate.persist(property) ; 

} 

public void updateProperty(Property property) { 
jpaTempl ate.merge(property) ; 

} 

public void setJpaTempl ate( JpaTempl ate jpaTemplate) { 
this. jpaTemplate = jpaTemplate; 

} 

} 
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L'avantage de l'utilisation d'un JpaTempl ate est son encapsulation directe des exceptions JPA 
en DataAccessExceptions Spring. Son inconvenient est son cote intrusif, par rapport a une 
approche 100 % JPA. 

La classe de support de DAO pour JPA, JpaDaoSupport, necessite aussi l'injection de 
1'EntityManagerFactory : 

<bean id="propertyDA0" 

cl ass-" tudu.domain.dao. j pa. Property DA0JpaSupport"> 
<property name="enti tyManager Factory" 
ref="entityManagerFactory" /> 
</bean> 

La classe de DAO doit heriter de JpaDaoSupport (dans le package org. spring- 
framework, orm.jpa. support. JpaDaoSupport) et peut acceder au JpaTempl ate via la methode 
getJpaTempl ate : 

public class PropertyDAOJpaSupport 

extends JpaDaoSupport implements PropertyDAO { 

public Property getProperty(String key) { 

return getJpaTempl ate( ) .f i nd( Property . cl ass , key) ; 

1 

(...) 

1 

Le choix d'utiliser la classe de support de DAO depend de la volonte d'introduire ou pas une 
hierarchie dans ses classes de DAO. 



Gestion des transactions 

Spring propose la classe JpaTransactionManager pour gerer les transactions. Celle-ci necessite 
une reference a 1'EntityManagerFactory : 

<bean id="transactionManager" 
class="org.springf ramework. orm.jpa. JpaTransactionManager "> 
<property name="enti tyManager Factory" 
ref="entityManagerFactory" /> 
</bean> 
(...) 

Les parametres transactionnels peuvent etre ensuite configures selon les differents moyens 
offerts par Spring (annotations, AOP, etc.), comme decrit dans le chapitre sur les transactions. 
II est important de noter que le support Spring pour JPA peut aussi s'integrer avec des transac- 
tions JTA, ou la transaction est fournie par le serveur d' applications et ou le JtaTran- 
sactionManager de Spring demarque les transactions. 

Le passage d'un environnement a F autre est un simple probleme de configuration : le code 
reste identique. 
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En resume 

Spring propose un support tres avance pour JPA. Ce support permet notamment une grande 
souplesse et une grande portabilite du code JPA. II est ainsi possible de coller completement 
au standard et d' avoir un code applicatif pratiquement directement portable vers un conteneur 
EJB 3.0. Spring complete cette approche avec une possibilite de decorer les DAO pour qu'ils 
puissent s'imbriquer dans une application en couches Spring. 

II est aussi possible de beneficier du support d'acces aux donnees de Spring via le JpaTempl ate 
et sa classe de DAO associee. On a alors un code applicatif moins portable, mais toujours 
tourne fortement vers le standard JPA. 



Solutions non standard isees 

Outre la solution de persistance standard qu'est JPA, il existe une offre importante de solutions 
d'ORM. Nous traitons ici de deux des plus populaires d'entre elles : iBATIS et Hibernate. 



iBATIS 

iBATIS est un projet de la fondation Apache se situant entre une solution JDBC pur et un outil 
d'ORM. En effet, iBATIS n'est pas un outil ORM a proprement parler, mais plutot un outil 
permettant d'effectuer des correspondances entre des requetes SQL et des objets Java. II laisse 
done une totale maitrise du SQL execute et gere completement la transformation des resultats 
en objets Java. iBATIS possede des implementations en .NET et en Ruby, ce qui permet de 
reutiliser des mappings iBATIS dans des applications codees dans ces differents langages. 

Le support pour SqIMapClient 

iBATIS propose un bon compromis pour ceux qui preferent controler exactement les requetes 
executees tout en souhaitant eviter le code fastidieux necessaire a l'exploitation des resultats. 
Lutilisation directe d'iBATIS se heurte cependant a deux problemes. Le premier concerne la 
gestion du contexte de persistance (un objet de type com.ibatis.sqlmap.cl ient.SqlMapCl ient) 
qui doit etre faite de facon programmatique. Cela implique Fecriture systematique d'un code 
assez contraignant. Le deuxieme probleme d'iBATIS reside dans sa politique d'exceptions : 
toutes les methodes de Sql MapCl i ent sont susceptibles de lancer des SQLExcepti on. Ce choix est 
contraignant et ne facilite pas l'utilisation de F API iBATIS : d'une part, les exceptions SQL sont 
explicites ; d' autre part, elles sont souvent trop generiques pour etre traitees correctement. 

Le support de Spring pour iBATIS permet de remedier a ces problemes et favorise la 
souplesse de configuration du contexte iBATIS grace a 1' inversion de controle. Nous allons 
voir comment utiliser iBATIS pour gerer les proprietes de Tudu Lists. 

II faut dans un premier temps definir les requetes SQL pour cette table. Cela se fait dans un 
fichier de mapping, appele par exemple Property .xml : 

<?xml version="1.0" encoding="llTF-8" ?> 
<!D0CTYPE sqlMap 

PUBLIC "-//ibatis. apache. org//DTD SQL Map 2.0//EN" 
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"http://ibatis .apache.org/dtd/sql -map-2.dtd"> 
<sqlMap namespace="Property"> 

<resultMap id="result" cl ass="tudu. domain. model . Property"><— Q 

<result property="key" col umn="pkey" /> 

<result property-"val ue" col umn="val ue" /> 
</resul tMap> 

<select id="getProperty" resultMap="result"><— Q 

select pkey, value from property where pkey = #key# 
</select> 

<insert id="saveProperty"><— Q 

insert into property (pkey, value) values (#key#, #value#) 
</insert> 

<update id="updateProperty"><— Q 
update property 

set pkey = #key#, value = #value# 
where pkey = #key# 
</update> 

</sqlMap> 

Le repere Q definit la correspondance entre une ou des requetes de selection et une classe 
Java. Cette definition explicite, nommee (result), permet de reutiliser cette correspondance. 
La requete de recuperation d'une propriete en fonction de son identifiant est effectuee au 
repere Q. La syntaxe #key# definit le passage d'un parametre. La correspondance result est 
utilisee pour exploiter le resultat de la requete SQL et le transformer en objet Java. Les 
reperes © et © definissent respectivement les requetes d'insertion et de mise a jour d'une 
propriete. 

Ce fichier de correspondance doit ensuite etre reference dans un fichier de configuration 
global d'iBATIS, appele generalement sqlmap-conf ig.xml : 

<?xml version="1.0" encoding="UTF-8" ?> 
<!D0CTYPE sqlMapConfig 

PUBLIC "-//ibatis. apache. org//DTD SQL Map Config 2.0//EN" 

"http://ibatis.apache.org/dtd/sql -map- config- 2. dtd"> 
<sqlMapConfig> 

<sqlMap resource="Property.xml " /> 
</sqlMapConfig> 

Ce fichier peut contenir un grand nombre d' informations pour iBATIS (politique trans action - 
nelle, connexion a une base de donnees...), mais ces elements sont generalement renseignes 
dans Spring si Ton utilise son support pour iBATIS. Ce support se traduit notamment par un 
template iBATIS. Voici comment le definir : 

<bean id="sqlMapCl ient" 

cl as s=" org. spri ngf ramewo rk.orm.ibatis.SqlMapCli en t Factory Bean "> 
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<property name="conf i g Location" 
value-"classpath:/sqlmap-config.xml " /> 
<property name="dataSource" ref="dataSource" /> 
</bean><^Q 

<bean id-"sqlMapCl ientTempl ate" 

class="org.springframework.orm.ibatis.SqlMapClientTemplate"> 
<property name="sqlMapClient" ref="sqlMapCl ient" /> 
</bean><-0 

<bean id="propertyDAO" 

class="tudu.domain.dao.ibatis.PropertyDAOIBatis"> 
<property name="sql MapCl ientTempl ate" 

ref="sqlMapClientTemplate" /> 
</bean><-© 

Spring cree le SqlMapClient via un SqlMapClientFactoryBean, auquel on doit passer une 
DataSource et la reference ail fichier de configuration sqlmap-config.xml (Q). Le 
SqlMapCl ient peut ensuite etre injecte a un SqlMapCl ientTempl ate, le template d'acces Spring 
dedie a iBATIS (©). Ce template va gerer pour nous le contexte d'iBATIS et encapsuler 
toutes les exceptions SQL dans des exceptions d'acces aux donnees de Spring. Un DAO est 
defini (©) et se voit injecte le template iBATIS. 

Voici 1' implementation de ce DAO : 

public class PropertyDAOIBati s implements PropertyDAO { 

private SqlMapClientTemplate sqlMapClientTemplate; 

public Property getProperty(String key) { 

return (Property) sqlMapCl ientTempl ate .queryForObject( 
"getProperty" , key 

); 

} 

public void saveProperty ( Property property) { 

sqlMapCl ientTempl ate. update ( "saveProperty" , property) ; 

} 

public void updateProperty(Property property) { 

sqlMapCl ientTempl ate. update ( "update Property" , property) ; 

} 

public void setSqlMapClientTemplate( 

SqlMapClientTemplate sqlMapClientTemplate) { 
this. sqlMapClientTemplate = sqlMapClientTemplate; 

} 

} 
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Assez simple, 1' implementation de DAO se fonde sur le template Spring pour iBATIS, qui 
propose une API tres epuree et utilise les references aux requetes definies dans le fichier 
Property .xml . 

Classe de DAO 

Spring propose aussi une classe de DAO pour iBATIS. Celle-ci dispose nativement d'un 
Sql MapCl i entTempl ate et necessite seulement le Sql MapCl i ent pour etre initialisee : 

<bean id-"propertyDAO" 

class="tudu.domain.dao.ibatis.PropertyDAOSupportIBatis"> 
<property name="sqlMapClient" ref="sqlMapClient" /> 
</bean> 

La classe de DAO doit heriter de SqlMapCl ientDaoSupport (dans le package 
org. springframework. orm.ibatis. support) et peut acceder au SqlMapCl ientTempl ate via la 
methode getSql MapCl i entTempl ate : 

public class PropertyDAOSupportlBati s 

extends SqlMapCl ientDaoSupport implements PropertyDAO { 

public Property getProperty(String key) { 

return (Property) getSql MapCl ientTempl ate( ) .queryForObject( 
"getProperty" , key 

); 

} 

(...) 

} 

Le choix d'utiliser la classe de support de DAO depend de la volonte d'introduire ou non une 
hierarchie dans ses classes de DAO. 

En resume 

Le support de Spring pour iBATIS est tres interessant en ce qu'il fluidifie fortement le code 
final, tout en apportant de la souplesse a la configuration. Choisir iBATIS par rapport a une 
autre solution 100 % SQL ou ORM est au final une question de gout. Ceux ay ant de tres 
bonnes competences en SQL, voulant controler toutes les requetes et privilegiant une solution 
simple, privilegieront iBATIS. Ceux preferant a tout prix eviter le SQL et laisser cette proble- 
matique a un outil prefereront une solution d'ORM. 



Hibernate 

Hibernate est sans conteste la solution d'ORM la plus populaire du monde Java. Cette popula- 
rite est due a sa simplicite, sa gratuite et bien sur ses excellentes performances. Hibernate est 
aussi largement documente, aussi bien sur Internet que par 1' intermediate d'ouvrages. 

Hibernate a ete au cceur de la definition de JPA 1.0, l'equipe d'Hibernate ayant participe a la 
JSR 220. Cependant, Hibernate est globalement plus riche que JPA, grace a sa maturite et 
parce que JPA subit Finertie inherente a tout standard. 
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Voici quelques fonctionnalites phares d' Hibernate : 

• Options de mapping avancees : Hibernate propose des options de mapping tres avancees, 
allant de 1' heritage a la gestion de composants en passant par des mappings complexes de 
collections. 

• Gestion des requetes : Hibernate dispose non seulement d'un langage de requete — le HQL 
(Hibernate Query Language) — , mais aussi d'une API programmatique pour la gestion de 
criteres (Criteria), ce qui fait defaut a JPA 1 .0. 

• Options de chargement : Hibernate peut effectuer des chargements a la demande (lazy 
loading), effectuant ainsi des requetes seulement si cela s'avere necessaire, mais aussi des 
chargements immediats (eager fetching) selon differentes methodes parametrables (batch 
fetching, jointure, etc.). 

• Contexte de persistance : Hibernate conserve une trace de tous les objets charges dans une 
unite de travail. Cela s'avere non seulement benefique pour les performances, mais aussi 
particulierement adapte aux applications Web. Ce principe a ete adopte dans JPA. 

La combinaison Spring-Hibernate constitue encore une excellente solution de persistance, 
bien que certains privilegient le standard avec JPA. JPA etant de toute facon encore limite par 
rapport a tous les outils d'ORM, il n'est pas rare d'ajouter quelques elements « proprietaries » 
a une application JPA, notamment au niveau du mapping. 

Le support de Spring pour Hibernate se traduit par des facilites de configuration, la possibilite 
d'integrer Hibernate a une gestion des transactions declaratives a la Spring et la gestion du 
contexte de persistance. Ce support permet done a la fois d'alleger et de fiabiliser toute appli- 
cation utilisant Hibernate. Concernant les versions d' Hibernate, il est important de noter que 
Spring 2.5 ne supporte qu' Hibernate 3.1 ou superieur. 

Creation d'une Session Factory (mapping XML) 

La configuration d'Hibernate passe par la creation d'une SessionFactory, qui contient toute la 
configuration d'Hibernate, notamment les informations de mapping. Cet objet est long a creer, 
mais il est threadsqfe une fois initialise. II est generalement gere comme un singleton. 

Une SessionFactory sert a creer des Sessions Hibernate, qui constituent le point d'entree pour 
une unite de travail de persistance. Une Sessi on est un objet qui n'est pas threadsafe et dont la 
duree de vie est generalement limitee a la requete utilisateur. Le cycle de vie d'une Session 
Hibernate est generalement identique a celui de la transaction base de donnees. 

Dans une application utilisant le support Spring pour Hibernate, la SessionFactory n'est jamais 
directement manipulee, seulement configuree par le contexte Spring. La Session Hibernate est 
quant a elle accessible, bien qu'on puisse lui preferer l'utilisation de l'Hi bernateTempl ate. 

Voici comment configurer une SessionFactory avec Spring : 

<bean id="sessionFactory" class=" 
org.springf ramework.orm.hibernate3. Local Ses s ion Factory Bean "><—© 
<property name="dataSource" ref="dataSource"/><— Q 
<property name="mappingResources"><— Q 
<list> 
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<val ue>property. hbm.xml </val ue><— Q 
</list> 
</property> 

<property name="hibernateProperties" 
ref=" hi bernateProperties "/><—© 
</bean> 

La SessionFactory est creee via une Local SessionFactoryBean (Q). II est important de noter 
que le package contient hibernate3, car le package org. springframework.orm. hibernate est 
reserve a Hibernate 2, qui n'est plus supporte dans les nouvelles versions de Spring. La 
SessionFactory necessite Finjection d'une DataSource (Q), qui peut provenir d'un appel 
JNDI ou de la configuration d'un pool de connexions dans le conteneur Spring. 

La propriete mapping Re sources (©) doit recevoir une liste de fichiers contenant le mapping 
objet/relationnel des differentes entites. Nous ne mappons ici que la classe Property de Tudu 
Lists (©), contenue dans le fichier property .hbm.xml, que nous detaillons par la suite. 

II est possible de passer a la SessionFactory un ensemble de parametres sous la forme de 
java.util .Properties (0). II est preferable de definir ces proprietes dans un Bean distinct, 
localise dans un fichier different, arm de pouvoir reutiliser la definition de la SessionFactory 
dans differents environnements. Voici un exemple de proprietes Hibernate (consulter la docu- 
mentation de reference d' Hibernate pour connaitre toutes les proprietes possibles) : 

<util rproperties id="hibernateProperties"> 
<prop key="hibernate.dialect"> 

org.hibernate.dialect.HSQLDialect 
</prop> 

<prop key="hibernate.hbm2ddl .auto">create-drop</prop> 
</util :properties> 

Ces reglages indiquent a Hibernate quel dialecte utiliser (il differe selon la base de donnees 
cible) et lui demandent de creer les tables en fonction du mapping au demarrage de la 
SessionFactory puis de les supprimer lors de sa destruction. Cette configuration est bien sur 
adaptee a un environnement de test. 

Le fichier de mapping XML de la classe Property est le suivant : 

<?xml version-"!.. 0"?> 

<!D0CTYPE hibernate-mapping PUBLIC 

"-//Hibernate/Hibernate Mapping DTD 3.0//EN" 

"http: / /hibernate. sourceforge.net/hibernate-mapping -3. 0.dtd"> 

<hibernate-mapping> 

<class name="tudu. domain. model .Property" tabl e="property"> 
<id name="key" col umn="pkey"> 

<generator cl ass-"assi gned" /> 
</id> 

<property name="val ue" col umn="val ue" /> 

</cl ass> 



</hi bernate-mapping> 
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II s'agit la d'un mapping relativement simple, propre a Hibernate, et nous ne nous attarderons 
pas dessus. 

La classe Property ressemble a ceci : 
package tudu. domain. model ; 
public class Property { 

private String key; 

private String value; 

public String getKeyO { 
return key; 

} 

public void setKey(String key) { 
this. key = key; 

} 

public String getValueO { 
return value; 

} 

public void setVal ue(String value) { 
this. value = value; 

} 

} 

La classe n'a aucune dependance vers une quelconque API (Spring, Hibernate ou JPA), meme 
pas a travers des annotations, ce qui est Favantage de la solution de mapping par XML. 

Utilisation de I' HibernateTemplate 

En accord avec le principe d'acces aux donnees de Spring, il existe un template d'acces pour 
Hibernate. Celui-ci a une API tres proche de la Sessi on Hibernate. II propose cependant quel- 
ques raccourcis interessants et a le merite d'encapsuler toute exception Hibernate en 
DataAccessException Spring. 

L'HibernateTemplate n'a besoin que d'une SessionFactory pour etre cree. Une fois initialise, 
il est threadsafe et peut done etre utilise par differents DAO dans toute application transac- 
tionnelle. Voici comment definir un HibernateTempl ate et Finjecter dans un DAO : 

<bean id="hibernateTemplate" 

cl ass-"org.springf ramework.o rm. hi be rnate3. HibernateTempl ate"> 
<property name-"sessionFactory" ref="sessionFactory"/> 
</bean> 

<bean id-"propertyDAO" 

cl ass-" tudu. domain.dao. hibernate. Property DAOHi bernate"> 
<property name="hibernateTempl ate" ref="hibernateTempl ate"/> 
</bean> 
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Le DAO peut alors tirer parti de 1' API de l'H1 bernateTempl ate : 
public class PropertyDAOHibernate implements PropertyDAO { 

private HibernateTemplate hibernateTemplate; 

public Property getProperty(String key) { 

return (Property) hibernateTemplate.get(Property. class, key); 

} 

public void saveProperty( Property property) { 
hi bernateTempl ate. saveOrUpda te( property ) ; 

} 

public void updateProperty ( Property property) { 
hibernateTempl ate. saveOrUpdate (property ) ; 

} 

public void setHibernateTemplate( 

HibernateTemplate hibernateTempl ate) { 
this.hibernateTemplate = hibernateTemplate; 

} 

} 

II est a noter qu'a partir de Spring 3.0, l'Hi bernateTempl ate tire parti des annotations Java 5. 
Cela evite notamment des transtypages lors de la recuperation d'objets via leur identifiant : 

public Property getProperty(String key) { 

return hibernateTemplate. get(Property. class, key); 

I 

Classe de DAO pour Hibernate 

Spring propose une classe de base pour DAO. Celle-ci inclut un HibernateTemplate et neces- 
site la SessionFactory pour etre initialisee : 

<bean id-"propertyDA0" 

class="tudu.domain.dao.hibernate.PropertyDAOSupportHibernate"> 
<property name="sessionFactory" ref="sessionFactory"/> 
</bean> 

Le DAO doit alors heriter de HibernateDaoSupport (dans le package org. spring- 
framework. orm.hibernate3. support). II peut acceder a FHibernateTemplate via la methode 
getHi bernateTempl ate : 

public class PropertyDAOSupportHibernate 

extends HibernateDaoSupport implements PropertyDAO { 

public Property getProperty(String key) { 
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return (Property) getHi bernateTempl ate( ) .get( 
Property. class, key 

); 

} 

(...) 

} 

Le choix d'utiliser la classe de support de DAO depend de la volonte d'introduire ou non une 
hierarchie dans ses classes de DAO. 

Creation d'une Session Factory (mapping avec annotations) 

Le mapping objet/relationnel avec Hibernate peut etre defini aussi bien avec des fichiers XML 
qu'avec des annotations sur les classes d'entites. II est alors possible d'utiliser soit les annota- 
tions JPA, soit les annotations Hibernate, ces dernieres permettant d'utiliser toutes les fonc- 
tionnalites d'Hibernate. Cependant, il est preferable d'utiliser les annotations JPA et de 
completer la configuration avec des annotations Hibernate. 

Pour creer une Sessi onFactory se basant sur des classes d'entites annotees avec Spring, il faut 
utiliser une AnnotationSessionFactoryBean : 

<bean id-"sessionFactory" class=" 
org. springf ramework.orm. hi bernate3. annotation. 
Annota tionSess ion Factory Bean "> 
<property name="dataSource" ref="dataSource"/> 
<property name="annotatedCl asses "> 
<list> 

<val ue>tudu. domain .model . Property </val ue> 
</list> 
</property> 

<property name="hibernateProperti es" ref="hibernateProperti es"/> 
</bean> 

La configuration est identique a la Local Sessi onFactoryBean si ce n'est qu'il faut maintenant 
lister directement les classes annotees plutot que les fichiers de mapping. Dans le cas d'un 
mapping simple comme celui de Property, la classe est annotee exactement comme dans un 
contexte JPA : 

package tudu. domain. model ; 

import javax.persi stence.Col umn ; 
import javax.persi stence. Entity ; 
import javax. persistence. Id; 
import javax. persistence. Table; 

©Entity 

@Tabl e(name="property" ) 
public class Property { 
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@Id 

@Col umn(name="pkey" ) 
private String key; 

@Col umn(name="val ue" ) 
private String value; 

/* getter / setter */ 
(...) 

} 

En resume 

Le couple Spring-Hibernate est une solution tres solide pour une couche de persistance. Si 
Hibernate apporte la puissance et les performances de son moteur ORM, Spring lui ajoute une 
grande souplesse, aussi bien au niveau de sa configuration que de son utilisation, en gerant 
pour le developpeur les ressources Hibernate (Session et transaction). 



Conclusion 

Meme si nous preconisons F utilisation d'un outil d'ORM pour toute application d'entreprise, 
l'utilisation directe de JDBC peut encore s'averer necessaire dans certains cas (traitements 
batch, utilisation d'operateurs specifiques a la base de donnees, refactoring d' applications 
JDBC existantes). Le support de Spring pour JDBC permet alors d'ameliorer la productivite 
et la robustesse du code, tout en laissant la possibilite de mettre un pied dans le monde de 
l'ORM avec le principe de RowMapper. 

Pour ceux qui hesitent a entrer dans ce monde et souhaitent utiliser au mieux leurs competen- 
ces SQL, iBATIS est une bonne solution, qui permet de faire cohabiter les deux mondes sans 
en privilegier un. Le support de Spring s'impose en ce cas, car il rend l'utilisation d'iBATIS 
beaucoup plus facile. 

Cependant, les outils d'ORM arrivent maintenant a maturite et ils sont a privilegier pour tout 
nouveau developpement. JPA, le standard, propose un ensemble de fonctionnalites interessan- 
tes, mais pas encore autant que la purpart des outils d'ORM. Cependant, il s'agit d'un stan- 
dard plutot bien accepte et qui evolue dans le bon sens. II est done important de le prendre en 
consideration. 

La plupart des produits d'ORM Java proposent une implementation JPA. Ces produits ajou- 
tent leurs propres fonctionnalites au-dessus de JPA, fonctionnalites parfois experimentales, 
mais toujours innovantes. Leur utilisation est done a privilegier si Ton souhaite profiter des 
dernieres evolutions de FORM, sans etre contraint par Finertie d'un standard. 

Quel que soit le choix d' outil ORM, Spring propose toujours un support pour la configuration 
et pour la gestion des problematiques courantes. Le code applicatif est alors extremement pur 
et portable, et les changements d'environnement deviennent seulement des problematiques de 
configuration. 
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Pour stocker des donnees et echanger des messages, les applications d'entreprise mettent en 
jeu de nombreuses ressources, telles que bases de donnees, serveurs de messagerie applica- 
tive, gros systemes, etc. Ces applications doivent maintenir une coherence entre ces differen- 
tes ressources afin de garantir la consistance des donnees en cas d'annulation de traitement, 
d'erreur, de bogue ou de panne. Au cceur des technologies Java/Java EE, le concept de tran- 
saction vise a resoudre ces problematiques de coherence. 

Ce chapitre passe en revue les principales notions inherentes aux transactions et explique 
comment le framework Spring permet de les mettre en ceuvre de maniere optimale dans une 
architecture, et ce, quels que soient les technologies ou frameworks sous-jacents employes. 

Rappels sur les transactions 

Oublier de gerer les transactions dans une application n'engendre pas necessairement de 
dysfonctionnement visible. Cependant, cet oubli ne permettant pas de garantir la consistance 
des donnees manipulees, des erreurs delicates a detecter peuvent survenir. 

Ces erreurs sont souvent difficiles a reproduire sans donnees de production et peuvent impac- 
ter tous les systemes d'information utilises par l'application. Par exemple, si les donnees rela- 
tives a un client n'ont pas ete correctement enregistrees dans les differentes sources de 
donnees de Fentreprise, des donnees erronees concernant ce client se retrouvent dans certaines 
applications tierces. 

La notion de transaction est done primordiale et doit etre mise en ceuvre dans toute application 
realisant des mises a jour dans des sources de donnees. 
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Proprietes des transactions 

Prenons un exemple concret tire de notre etude de cas Tudu Lists. L'importation d'une liste de 
todos en mode modification est particulierement appropriee, puisqu'il s'agit de fusionner les 
valeurs des elements de la nouvelle liste avec celles de l'ancienne. 

Imaginons que ce traitement echoue a sa moitie : les donnees de la liste ne sont des lors pas 
homogenes. La premiere partie correspond a des donnees de la nouvelle liste, et la seconde a 
des donnees de l'ancienne. Ces dernieres donnees n'ont pas ete modifiees puisque l'execution 
s'est arretee avant leur traitement. 

Les transactions permettent de pallier ce probleme, un de leurs objectifs etant d' assurer 
F atomicite d'un traitement. Si une erreur se produit dans l'importation, les modifications ne 
sont pas repercutees en base, et les donnees de la liste restent dans leur etat initial. La liste 
n'est modifiee en base que si le traitement se deroule correctement jusqu'a son terme. 

Le role des transactions est done de valider les modifications realisees par des traitements 
d'une methode si aucune erreur ne se produit et de les annuler dans le cas contraire. De cette 
maniere, les donnees restent coherentes. Ajoutons qu'une fois les modifications sur les 
donnees validees, celles-ci doivent etre durables. 

L exemple precedent montre qu'une transaction doit etre une unite de traitements (unit of 
work). De la sorte, toutes les modifications realisees par ces traitements doivent etre validees 
ou annulees en meme temps. 

Une transaction doit en outre verifier les proprietes fondamentales suivantes, communement 
designees sous l'acronyme ACID (atomicite, consistance, isolation, durabilite) : 

• Atomicite. Tous les traitements realises dans une transaction sont vus par 1' application 
comme une seule unite et sont done indivisibles. 

• Consistance. Les donnees des differents systemes ne peuvent rester dans des etats inco- 
herents. Ces etats sont, par exemple, des transitions necessaires au cours des differents 
traitements de la transaction, ces derniers pouvant n'etre pas visibles au moment de son 
achevement. 

• Isolation. Definit la visibilite des etats internes de la transaction par le reste de F application 
au cours de sa realisation. Suivant les sources de donnees et les technologies utilisees, 
Fisolation peut avoir plusieurs niveaux. 

• Durabilite. Lorsqu'une transaction est validee, les modifications realisees sur les differentes 
donnees sont definitives et entierement visibles par le reste des applications qui utilisent la 
source de donnees. 

Granularite des transactions 

Les transactions peuvent avoir plusieurs niveaux de granularite transactionnelle, allant des 
transactions simples aux transactions imbriquees : 

• Transactions simples. En vertu des proprietes ACID, une transaction simple est un bloc 
indivisible, qui possede done une granularite importante. Elle correspond a une boite noire 
contenant les differents traitements. 
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• Transactions imbriquees. Pour les systemes compatibles, il est possible de realiser des 
transactions imbriquees, a la granularite plus fine. Elles consistent en des sous-blocs 
transactionnels au sein d'une meme transaction. Ces blocs peuvent etre annules indepen- 
damment de la transaction ou valides en meme temps que cette derniere. 

Isolation transactionnelle 

Certains systemes d'information autorisent differents niveaux d'isolation afin de permettre 
aux applications de maitriser completement les donnees visibles a l'exterieur de la transac- 
tion. Les applications peuvent de la sorte jouer indirectement sur les performances d'acces 
aux donnees puisque cette propriete s'appuie generalement sur des mecanismes de gestion de 
la concourance d'acces et de verrous. 

Les bases de donnees relationnelles sont un exemple classique de systeme d'information utili- 
sant ce mecanisme. Ces bases de donnees fournissent plusieurs niveaux d'isolation des 
donnees lors de leur manipulation au cours d'une transaction, qui ne correspondent pas tous a 
une isolation stricte des donnees et peuvent done entramer des problemes, comme le recapi- 
tule le tableau 11-1. 



Tableau 11-1.Typologie des problemes induits par les transactions 



Type de probleme 


Description 


Dirty Read 
(lecture sale) 


Un fil d'execution voit des donnees d'une transaction sans que celle-ci soit termi- 
nee. De ce fait, les donnees se trouvent dans un etat transitoire au moment de la 
lecture. L'utilisation et la manipulation des valeurs de ces donnees peuvent entrai- 
ner des incoherences au niveau des donnees. 


Non-Repeatable Read 
(lecture non reproductible) 


Une lecture recupere des donnees dans un certain etat dans la transaction. Si une 
application modifie ces donnees parallelement, la meme lecture renvoie ces don- 
nees modifiees. La transaction n'est done pas completement isolee vis-a-vis des 
donnees modifiees par les autres transactions. De ce fait, les lectures ne sont pas 
reproductibles. 


Phantom Read 
(lecture fantome) 


Contrairement aux lectures non reproductibles, qui impliquent une modification 
des donnees, les lectures fantomes sont la consequence d'insertions ou de sup- 
pressions de donnees entre leur lecture et leur utilisation. 



II est important de bien center les problemes eventuels pour chaque niveau d'isolation et de 
positionner ces niveaux avec precaution. Ces problemes etant tous issus d'acces concourants 
aux donnees, le developpeur de 1' application doit identifier avec precision les differents traitements 
possibles accedant simultanement aux donnees. 

Les bases de donnees relationnelles definissent plusieurs niveaux d'isolation. Le tableau 11-2 
les recapitule, du plus large au plus restrictif. 

Pour garantir l'integrite des donnees lors d'une transaction, il est imperatif de positionner le 
niveau d'isolation des donnees de maniere appropriee. II convient pour cela d'evaluer avec 
precision les differents types d'acces aux donnees, notamment les acces concourants en modi- 
fication. 
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Tableau 11-2 Niveaux d'isolation des bases de donnees relationnelles 



Niveau d'isolation 




Description 


TRANSACTION. 


.NONE 




Les transactions ne sont pas supportees. 


TRANSACTION. 


.READ. 


.UNCOMMITTED 


[.'application peut rencontrer les trois problemes evoques au 
tableau 1 1 -1 . En cas d'absence d'acces concourant aux donnees, 
ce niveau peut etre utilise afin d'ameliorer les performances. Ce 
n'est toutefois pas conseille, car la coherence des donnees n'est 
pas completement garantie. 


TRANSACTION. 


.READ. 


.COMMITTED 


Permet de resoudre les lectures non reproductibles, mais I'applica- 
tion peut eventuellement rencontrer les deux autres problemes. 


TRANSACTION. 


_REPEATABLE_READ 


Permet de resoudre les lectures non reproductibles et les lectures 
sales. Lapplication peut toutefois rencontrer des lectures fanto- 
mes. II s'agit du niveau d'isolation par defaut de beaucoup de ser- 
veurs de bases de donnees, dont Oracle. 


TRANSACTION. 


.SERIALIZABLE 


Permet de resoudre les trois problemes, mais au prix d'une degrada- 
tion des performances du fait des verrous poses sur les donnees 
accedees. 



Plus le niveau d'isolation est restrictif, plus la qualite et la coherence des donnees sont garan- 
ties. Cependant, comme nous allons le voir par la suite, une gestion de la concourance est 
souvent necessaire au niveau applicatif. 



Types de transactions 

II existe deux grands types de transactions, les transactions locales et les transactions globales. 
Leurs principales proprietes sont les suivantes : 

• Transactions locales. Adaptees lorsqu'une seule ressource transactionnelle est utilisee. 
Dans ce cas, le gestionnaire de transactions est la ressource elle-meme. Dans Fexemple 
precedent d' importation, toutes les donnees sont importees dans la meme source de stockage 
des donnees. 

• Transactions globales. Utilisables si une ou plusieurs ressources sont presentes. A partir de 
deux ressources, nous sommes toujours en presence de transactions globales. En cas d' utili- 
sation des transactions globales, le gestionnaire de transactions est externalise par rapport 
aux ressources et est capable de dialoguer avec elles grace a des interfaces normalisees. 
Dans notre exemple, les donnees sont importees dans differentes sources de stockage 
des donnees. 



Ressource transactionnelle 

On appelle ressource transactionnelle tout module d'acces a un systeme d'information, gerant des tran- 
sactions et offrant une interface de programmation afin de les configurer et de les utiliser. 



L' utilisation d'une seule base de donnees n'implique pas necessairement des transactions 
locales. Par exemple, si F application utilise en plus JMS comme middleware de messagerie 
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applicative, les transactions globales sont necessaires afin de realiser des transactions utilisant 
les deux ressources. 

Les transactions globales sont cependant beaucoup plus difficiles a mettre en ceuvre. En effet, 
ce type de transaction necessite la mise en ceuvre d'un gestionnaire de transactions externe. 
Ce dernier est souvent fourni par le serveur d' applications. L' inconvenient de ce type de 
mecanisme vient de la synchronisation des etats transactionnels des ressources et de la resolu- 
tion des incidents. Les systemes peuvent se retrouver dans des etats incoherents, lesquels 
doivent etre resolus par le biais de choix arbitraires. 

Une autre grande difference entre les transactions locales et globales est que ces dernieres se 
fondent sur F API uniformisee JTA (Java Transaction API), alors que les transactions locales 
s'appuient directement sur les API des technologies ou frameworks utilises. Nous retrouvons 
cependant toujours des methodes similaires pour demarrer une transaction, ainsi qu'une 
methode pour la valider et une methode pour Fannuler. 

Cette section ne detaille pas les differentes facons de gerer les transactions locales suivant les 
technologies et frameworks utilises mais se concentre sur la facon de les utiliser avec le 
framework Spring. Ce dernier masque toute cette complexite et cette diversite derriere une 
API generique. 

Gestion des transactions 

Plusieurs operations peuvent etre realisees afin de manipuler les transactions. II est en outre 
generalement possible de detecter les evenements du cycle de vie d'une transaction. 

Demarcage d'une transaction 

Une transaction est limitee par un debut et une fin. Cette derniere peut survenir aussi bien lors 
d'une validation, en cas de succes, que d'une annulation, en cas d'echec. La demarcation 
consiste a specifier le commencement et la fin de la transaction. 

Le code suivant montre comment demarquer une transaction avec JDBC, les traitements 
correspondant etant mis en ceuvre en se fondant sur la methode setAutoCommit (Q) pour le 
debut de la transaction, la methode commi t (Q) pour sa validation et la methode rollback (©) 
pour son annulation : 

Connection connection = null; 
try { 

//Recuperation de la connexion 
connection = getConnection( ) ; 

//Demarrage de la transaction 
connection .setAutoCommi t(fal se) ;<— O 

//Execution des traitements JDBC de 1 ' appl ication 
//... 
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//Validation de la transaction 
connection. commit( ) ;<— Q 
connection . setAutoCommit(true) ; 
} catch(SQLException ex) { 
//Gestion des exceptions 

//Annulation de la transaction 
try { 

connection . rol 1 back( ) ;<— © 

connection . setAutoCommit( true) ; 
} catch(SQLException ex) { } 
} finally { 

//Liberation des ressources JDBC 
try { 

if (connection!=null ) { 
connection .cl ose( ) ; 

} 

} catch(SQLException ex) { } 

} 

Dans ce code, il est a noter que le mode auto-commit est repositionne sur la connexion une 
fois la transaction terminee. 

En cas de succes d'une transaction, le terme commit est communement employe. Dans le cas 
contraire, on parle de rollback. Toutes les modifications entre le debut et la validation ou annu- 
lation de la transaction sont atomiques. 

Suspension et reprise d'une transaction 

Certains frameworks ou technologies permettent de suspendre une transaction dans le but de 
realiser des traitements et de la reprendre ensuite une fois ceux-ci termines. L implementation 
de ces actions se fait de maniere differente suivant le type de transaction choisi. 

Dans le cas des transactions locales, la suspension consiste a ne plus utiliser la connexion atta- 
chee a la transaction tout en la memorisant, puisqu'elle sera reutilisee quand la transaction 
reprendra. Lors de la suspension, une nouvelle connexion est utilisee. Nous pouvons en 
deduire que la suspension est logique et non physique et qu'il incombe au framework qui offre 
cette fonctionnalite de prendre en charge 1' implementation du mecanisme de suspension et de 
reprise. 

En ce qui concerne les transactions globales, la suspension tout comme la reprise se realisent 
directement en utilisant le gestionnaire de transactions et les methodes suspend et resume. La 
premiere renvoie la transaction courante suspendue. Pour la reprendre, la methode resume est 
appelee avec pour parametre cette transaction. L' application doit done avoir acces au gestion- 
naire de transactions globales. 

Le code suivant evoque la maniere de suspendre et de reprendre une transaction avec JTA, 
FAPI Java EE de gestion des transactions globales : 

// Recuperation du gestionnaire de transactions 
TransactionManager tm=getTransactionManager( ) ; 
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II Suspension de la transaction courante 
Transaction transaction=tm.suspend( ) ; 

// Reprise de cette transaction 
tm. resume (transact ion) ; 

Gestion du cycle de vie d'une transaction 

Certains frameworks ou technologies offrent la possibilite de declencher des traitements a 
differents moments du cycle de vie de la transaction. Le terme synchronisation est commune - 
ment utilise pour designer ce mecanisme. 

Les evenements du cycle de vie pris en compte se produisent essentiellement au moment de 
la validation ou de la finalisation de la transaction. Cela permet de liberer des ressources si 
necessaire. On distingue a cet effet les evenements avant la validation d'une transaction 
pour une ressource transactionnelle (commit) et ceux avant ou apres la finalisation de la 
transaction. Des evenements sur la suspension/reprise d'une transaction peuvent egalement 
etre supportes. 

Dans certains cas, comme avec JTA, ce mecanisme est directement integre a 1' API de gestion 
des transactions, tandis que des frameworks tels que Spring declenchent les evenements au 
cours du cycle de vie de la transaction. 

Les transactions definissent de maniere classique differents evenements. Ces evenements, 
recapitules au tableau 11-3, ne sont toutefois pas toujours supportes par les technologies ou 
frameworks. 



Tableau 11-3 Comportements transactionnels 



Evenement 


Description 


Sur la suspension 


Declenche lorsque la transaction est suspendue par I'application. 


Sur la reprise 


Declenche lorsque I'application reprend le deroulement de la transaction. 


Avant la validation 


Declenche avant qu'une ressource transactionnelle soit validee. 


Avant la finalisation 


Declenche avant que la transaction soit validee dans sa globalite. 


Apres la finalisation 


Declenche apres que la transaction a ete validee dans sa globalite. 



Types de comportements transactionnels 

Lorsqu'un composant est rendu transactionnel, il peut etre configure afin de specifier le 
comportement transactionnel de ses methodes. La plupart des frameworks ou technologies 
gerant les transactions definissent des mots-cles pour cela. 

Le tableau 11-4 recapitule ces mots-cles. II ne s'agit pas a proprement parler d'une specifica- 
tion, meme si ces mots-cles sont utilises plus ou moins entierement par des frameworks ou 
technologies tels que Spring ou les EJB. Ces mots-cles sont utiles lors d'appels entre des 
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methodes de differents composants dans un contexte transactionnel, comme des appels entre 
services metier. 



Tableau 11-4 Mots-cles de comportements transactionnels 



Mot-cle de comportement 
transactionnel 


Description 


REQUIRED 


La methode doit forcement etre executee dans un contexte transactionnel s'il 
existe. S'il n'existe pas lors de I'appel, il est cree. 


SUPPORTS 


La methode peut etre executee dans un contexte transactionnel s'il existe. Dans 
le cas contraire, la methode est tout de meme executee, mais hors d un contexte 
transactionnel. 


MANDATORY 


La methode doit forcement etre executee dans un contexte transactionnel. Si tel 
n'est pas le cas, une exception est levee. 


REQUIRESJJEW 


La methode impose la creation d'une nouvelle transaction pour la methode. 


NONSUPPORTED 


La methode ne supporte pas les transactions. Si un contexte transactionnel 
existe lors de son appel, celui-ci est suspendu. 


NEVER 


La methode ne doit pas etre executee dans un contexte transactionnel. Si tel est 
le cas, une exception est levee. 


NESTED 


La methode est executee dans une transaction imbriquee si un contexte transac- 
tionnel existe lors de son appel. 



La figure 11-1 illustre ce qui se passe au niveau des transactions pour ce type d'appel. La 
methode des premier et troisieme composants necessite une transaction (REQU I RED), et celle du 
second aucune (NONSUPPORTED). La transaction initiee par le premier composant est done 
suspendue le temps d'executer la methode du second puis reprend pour executer le troisieme. 



Figure 11-1 

Exemple de mecanisme 
transactionnel fonde 
sur les comportements 



Composant 1 



REQUIRED 



Methode! () 



Composant 2 



NOT SUPPORTED 



Methode2() 



Composant 3 



REQUIRED 



Methode3() 



-X- 



-x- 



Utilisation de la 
transaction courante 



Suspension de la 
transaction courante 



Utilisation de la 
transaction courante 
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Le tableau 1 1-5 recapitule la transaction utilisee par un composant suivant le type de compor- 
tement transactionnel specifie et la transaction en cours, Tl et T2 designant des transactions 
differentes. 



Tableau 11 -5 Types de comportements et transactions 



lype ae componemeni iransdcuonnei 


iransacTion iniiidie 


iransacTion utnisee 


REQUIRED 


Aucune 


T1 




T1 


I 1 


SUPPORTS 


Aucune 


Aucune 




T1 


T1 


MANDATORY 


Aucune 


Erreur 




T1 


T1 


REQUI RES_N EW 


Aucune 


T1 




T1 


T2 


N0T_SUPP0RT 


Aucune 


Aucune 




T1 


Aucune 


NEVER 


Aucune 


Aucune 




T1 


Erreur 


NESTED 


Aucune 


T1 




T1 


T1 (imbriquee) 



Ressources transactionnelles exposees 

Pour pouvoir utiliser les transactions globales, les fournisseurs de services etendent leurs 
fabriques de connexions afin de les rendre compatibles XA. La specification XA (extended 
Architecture) standardise les interactions entre les gestionnaires de ressources et le gestion- 
naire de transactions de facon a mettre en ceuvre des protocoles transactionnels. Cela permet 
de faire participer ces fabriques a une transaction globale. 

Le point fondamental pour le composant qui utilise la technologie ou le framework est que 
la fabrique exposee est toujours la fabrique simple, et non celle compatible XA. Un 
composant qui utilise les transactions locales ou globales ne voit done pas de difference 
quant aux entites qu'il manipule. Le fournisseur de services ou le serveur d' applications a 
pour sa part la responsabilite de masquer la fabrique XA derriere une fabrique classique, 
de fournir une connexion classique et d'ajouter et d'enlever la ressource du contexte tran- 
sactionnel. 

Le passage des transactions locales aux transactions globales n'a done aucun impact sur 
l'utilisation des ressources. La modification est localisee au niveau de la gestion de la demar- 
cation. Si celle-ci est declarative, le composant n'est pas impacte par un changement de type 
de transaction. Cela favorise fortement la reutilisation des composants dans differentes archi- 
tectures. 
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Gestionnaires de transactions JTA 

Afin de mettre en ceuvre les transactions globales, il est imperatif d'utiliser un gestionnaire de 
transactions JTA, ces derniers implementant les protocoles transactionnels correspondants. La 
plupart du temps, ce gestionnaire est mis a disposition par le serveur d' applications dans 
lequel est deployee l'application. 

Cependant, dans le cadre d' applications Spring ne necessitant qu'un conteneur Web, il est 
dommage d' avoir a utiliser un serveur d' applications Java EE complet lorsque F utilisation des 
transactions globales est requise. 

Ainsi, afin de mettre en ceuvre des transactions globales dans un conteneur Web, il existe 
d'interessants gestionnaires de transactions compatibles JTA autonomes, gestionnaires 
pouvant etre configures simplement dans ce contexte. Le tableau 11-6 recapitule les princi- 
paux outils de ce type. 



Tableau 11-6. Principaux gestionnaires de transactions JTA autonomes 



Gestionnaire transactionnel 


Description 


Atomikos JTA/XA 


Gestionnaire de transactions JTA propose par la societe Atomikos. Cet outil correspond a 
la version « communaute » du produit commercial ExtremeTransaction. II est disponible en 
version libre a I'adresse http://www.atornikos.com/Main/AtomikosCommunity. 


Bitronix Transaction Manager 


Outil offrant une implementation simple mais complete de la version 1.0.1 de JTA. Son 
atout principal est sa simplicity de mise en ceuvre et sa capacite a diagnostiquer les pro- 
blemes. II est disponible a I'adresse http://docs.codehaus.org/display/BTM/Home. 



Dans le cadre d' Atomikos, une integration Spring est utilisable afin de configurer F outil sous 
forme de Beans, comme dans le code suivant, oil l'un est dedie au gestionnaire (Q) et F autre 
a Finterface de demarcation des transactions (Q). Ces Beans peuvent ensuite etre injectes 
(©) dans le gestionnaire de transactions de Spring dedie a la technologie JTA : 

<!-- Configuration du TransactionManager d'Atomikos --> 
<bean id-"atomi kosTransactionManager"<— Q 

cl ass-"com.atomi kos. i catch. jta.UserTransactionManager" 

init-method="ini t" des troy -met hod="cl ose"> 
<property name="forceShutdown" val ue="f al se" /> 
</bean> 

<!-- Configuration du UserTransaction d'Atomikos --> 
<bean id="atomi kosUserTransaction"<— Q 

cl ass="com.atomi kos . i catch . jta . UserTransaction Imp" > 
<property name="transactionTimeout" value="300" /> 
</bean> 

<!-- Configuration du gestionnaire de transactions de Spring --> 
<bean id="jtaTransactionManager" class-"org.springframework 

. trans act i on. jta . JtaTransactionManager"> 



<property name=" trans act i onManager"<— Q 

ref="atomi kosTransactionManager" /> 

<property name="userTransacti on"<— Q 

ref="atomi kosUserTransaction" /> 

</bean> 
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Concourance d'acces et transactions 

Les applications Java EE utilisant par essence plusieurs fils d' execution pour gerer leurs diffe- 
rents traitements, plusieurs acces ou requetes de clients peuvent etre concourants. 

Afin d'eviter les ecrasements de donnees entre utilisateurs, les techniques de verrouillage 
suivantes peuvent etre mises en ceuvre (les techniques decrites ci-apres sont orientees base de 
donnees relationnelle) : 

• VeiTouillage pessimiste. Ce mecanisme de verrouillage fort est gere directement par le 
systeme de stockage des donnees. Pendant toute la duree du verrou, aucune autre applica- 
tion ou fil d' execution ne peut acceder a la donnee. Pour les bases de donnees relationnelles, 
cela se gere directement au niveau du langage SQL. A l'image d'Hibernate, plusieurs 
frameworks facilitent l'utilisation de ce type de verrou. Une requete SQL de type select 
for update est alors utilisee. 

Ce verrouillage particulierement restrictif peut impacter les performances des applications. En 
effet, ces dernieres ne peuvent acceder a Fenregistrement tant que le verrou n'est pas leve. Des 
fils d' execution peuvent done rester en attente et penaliser les traitements de F application. 

• Verrouillage optimiste. Ce type de verrouillage est plus large et doit etre implemente dans 
1' application elle-meme. II ne necessite pas de verrou dans le systeme de stockage des 
donnees. Pour les bases de donnees relationnelles, il est generalement implemente en ajou- 
tant une colonne aux differentes tables impactees. Cette colonne represente une version ou 
un indicateur de temps indiquant l'etat de Fenregistrement lorsqu'il est lu. De ce fait, si cet 
etat change entre la lecture et la modification, nous nous trouvons dans le cas d'un acces 
concourant. 

L' application peut implementer plusieurs strategies pour resoudre ce probleme. L'utilisateur 
peut etre averti, par exemple, par une interface conviviale lui offrant la possibility de voir les 
modifications realisees par un autre utilisateur conjointement avec les siennes. II peut des lors 
effectuer ses mises a jour. L' application peut aussi ne pas notifier l'utilisateur et implementer 
un mecanisme afin de fusionner les differentes donnees. 



En resume 

Situees au cceur des applications d'entreprise, les transactions visent a garantir Fintegrite des 
donnees des systemes d' information. Du fait qu'elles mettent en jeu de nombreuses notions 
qui peuvent etre complexes, il est preferable de les mettre en ceuvre en utilisant des technologies 
ou frameworks encapsulant toute leur complexite technique. 

La section suivante detaille la fa?on de les mettre en ceuvre, ainsi que les pieges a eviter et la 
solution fournie par le framework Spring. 
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Mise en oeuvre des transactions 

Depuis le debut de ce chapitre, nous avons rappele les differentes proprietes des transactions. 
Nous abordons a present leur mise en oeuvre optimale et de la facon la plus transparente possi- 
ble pour les composants des applications Java/Java EE. L'objectif vise n'est pas d'incorporer 
les mecanismes transactionnels dans le code des composants applicatifs, mais de le specifier 
au moment de leur assemblage. 

Integrer les notions transactionnelles dans 1' architecture d'une application n'est pas chose 
aisee, tant les concepts en jeu sont nombreux. Les principaux defis sont de conserver la 
modularite des composants, l'isolation des couches et la separation des codes technique et 
metier. 

Afin de concilier les bonnes pratiques abordees au cours des chapitres precedents et la gestion 
transactionnelle, la demarcation doit etre correctement appliquee et le comportement transac- 
tionnel des composants judicieusement utilise. Pour cela, 1' utilisation de frameworks ou de 
technologies appropries est indispensable. 

Gestion de la demarcation 

La demarcation transactionnelle doit etre realisee au niveau des services metier. Ces derniers 
peuvent s'appuyer sur plusieurs composants d'acces aux donnees. Plusieurs appels a des metho- 
des de ces composants sous-jacents peuvent done etre realises dans une meme transaction. 

Le support des transactions doit de plus etre suffisamment flexible pour permettre de gerer les 
appels entre services. La definition de types de comportement transactionnel rend ce support 
flexible et declaratif. Spring implemente ces strategies dans sa gestion des transactions. 

La figure 11-2 illustre les couches applicatives impactees par la gestion des transactions, qui 
est une problematique transversale. 



Couche 
presentation 



Couche 
application 



Couche 
services metier 



Couche 
acces aux 
donnees 



Couche 
persistance 



Portee du contexte transactionnel 
et composants transactionnels 



Demarcation 
transactionnelle 



Figure 11-2 

Impact de la gestion transactionnelle sur les couches applicatives 
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Dans notre etude de cas, V application des comportements transactionnels est mise en ceuvre 
surles composants du package tudu. service. impl. 



Mauvaises pratiques et anti-patterns 

La structuration des preoccupations en couches constitue une bonne pratique elementaire, 
chaque couche ne devant avoir connaissance que de la couche immediatement inferieure. 

Les composants services metier ne doivent s'appuyer que sur les composants d'acces aux 
donnees et ne peuvent en aucun cas avoir connaissance des API utilisees par ces composants 
pour acceder aux donnees. Cependant, la tentation est grande d'utiliser les API de persistance 
pour demarquer les transactions au niveau de la couche metier et de passer ensuite ces instan- 
ces aux couches inferieures. Par exemple, l'utilisation d'une connexion JDBC ou d'une 
session d'un outil d'ORM dans la couche service metier est un anti-pattern. 

Le code suivant est un bon exemple de mise en ceuvre de cet anti-pattern. II montre un 
composant de la couche service metier qui s'appuie sur une connexion JDBC arm de debu- 
ter et valider ou d'annuler une transaction locale (©). Cette connexion est ensuite passee au 
composant d'acces aux donnees utilise (Q) arm d'inclure les traitements du composant dans 
la transaction. 

Nous considerons dans ce code que Finstance monDao du composant d'acces aux donnees a ete 
correctement recuperee precedemment : 

Connection connection = null; 
try { 

//Recuperation de la connexion 
connection = getConnecti on( ) ; 

//Demarrage de la transaction 
beginTrans act ion (connect ion) ;<— © 

//Execution des traitements du DAO utilise 
monDao. update (connect ion , monEnti te) ;<— Q 

//Validation de la transaction 
commitTransacti on (connection) ;<— O 
} catch(SQLException ex) { 
//Gestion des exceptions 

//Annulation de la transaction 
rol 1 backTransacti on (connection) ;<— © 
} finally { 

//Liberation des ressources JDBC 
closeConnection(connection) ; 

} 

II existe un couplage fort entre les technologies utilisees par les composants de la couche 
d'acces aux donnees et les services metier, ces derniers utilisant ces technologies explicitement. 
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Cette pratique nuit grandement a la flexibilite, a la modularite, a Fevolutivite et a la separation 
des preoccupations. 

Une bonne pratique consiste a masquer 1' utilisation de ces API derriere une API generique de 
gestion transactionnelle. Cette API doit etre programmed a Faide d'interfaces arm de cacher 
F implementation de ce gestionnaire. Ce dernier peut eventuellement s'appuyer sur un 
contexte trans actionnel pour le fil d' execution et etre stocke dans une instance de type 
ThreadLocal . Cette classe de base de Java permet de garder une instance pouvant rester acces- 
sible pour tout un fil d'execution. 

La section suivante detaille comment Spring permet de gerer facilement et de facon modulaire 
les transactions dans les applications Java/Java EE a l'aide de bonnes pratiques de conception 
et de fonctionnalites permettant de specifier des comportements transactionnels de maniere 
declarative. 

L'approche de Spring 

L'une des fonctionnalites les plus attractives de Spring est indiscutablement celle qui 
concerne la gestion des transactions, car elle offre une souplesse et une facilite d' utilisation 
sans egales dans le monde Java/Java EE. 

La strategic de Spring est en outre entierement configurable et modulaire. Nous verrons qu'il 
existe deux approches pour gerer la demarcation, s'appuyant toutes deux sur une API de 
demarcation generique, et plusieurs implementations de la strategie transactionnelle en fonc- 
tion des ressources utilisees. Spring permet ainsi de s'adapter aux besoins de l'application et 
de maitriser le degre d'intrusivite ainsi que les performances de la gestion des transactions en 
utilisant le type de transaction approprie. 

Spring permet en outre de definir des comportements transactionnels sur les composants par 
declaration. 

Une API generique de demarcation 

Les concepteurs de Spring ont identifie le besoin d'une API generique afin de gerer la demar- 
cation transactionnelle et de specifier le comportement transactionnel d'un composant. 

Cette API comporte deux grandes parties, la partie cliente et la partie fournisseur de services. 
Partie cliente 

La partie cliente permet de demarquer explicitement la transaction, soit directement avec les 
API transactionnelles de Spring, soit indirectement avec un template transactionnel ou un 
intercepteur. 

Toutes les classes et interfaces decrites dans cette section sont localisees dans le package 
org. springframework. transaction du framework. 

Le premier element du support transactionnel est 1' interface PI atf ormTransacti onManager, qui 
permet de demarquer une transaction, et ce, quelles que soient les ressources et strategies 
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transactionnelles utilisees. Cette interface foumit des methodes de validation et d'annulation 
pour la transaction courante : 

public interface PlatformTransactionManager { 
TransactionStatus getTransaction( 

Transacti onDefi nit ion definition) 

throws TransactionException; 
void commit(TransactionStatus status) 

throws TransactionException; 
void rollback(TransactionStatus status) 

throws TransactionException; 

} 

Pour commencer une transaction, les proprietes et comportements transactionnels suivants 
doivent etre specifies : 

• isolation trans actionnelle ; 

• type de comportement transactionnel ; 

• temps d' expiration des transactions ; 

• statut lecture seule. 

Ces proprietes sont contenues dans l'interface Transact!' onDefiniti on suivante : 

public interface TransactionDefinition { 
int PROPAGATION_REQU I RED = 0; 
int PR0PAGATI0N_SUPP0RTS = 1; 
int PR0PAGATI0N_MANDAT0RY = 2; 
int PROPAGATION„REQUIRES_NEW = 3; 
int PR0PAGATI0N_N0T_SUPP0RTED = 4; 
int PROPAGATIONJJEVER = 5; 
int PROPAGATIONJJESTED = 6; 



int IS0LATI0OEFAULT = -1; 

int ISOLATION_READ_UNCOMMITTED = 

Connection .TRANSACTION_READJJNCOMMITTED; 
int IS0LATI0N_READ_C0MMITTED = 

Connection .TRANSACT 1 0N_READ_C0MMITTED; 
int ISOLATION_REPEATABLE_READ = 

Connection .TRANSACTION_REPEATABLE_READ; 
int IS0LATI0N_SERIALIZABLE = 

Connection .TRANSACTION_SERIALIZABLE; 



int getPropagationBehaviort ) ; 
int getlsol ati onLevel ( ) ; 
int getTimeout( ) ; 
boolean i sReadOnly( ) ; 
String getNameO; 
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Spring supporte tous les types de comportements transactionnels decrits precedemment. Les 
mots-cles coiTespondants different toutefois legerement des mots-cles generaux, comme le 
montre le tableau 1 1-7. 



Tableau 11-7. Comportements transactionnels de Spring 



Comportement transactionnel general 


Mot-cle Spring 




REQUIRED 


PROPAGATION_REQUI RED 




SUPPORTS 


PR0PAGATI0N_SUPP0RTS 




MANDATORY 


PR0PAGATI0N_MANDAT0RY 




REQUIRES_NEW 


PROPAGATION_REQUIRES_NEW 




N0T_SUPP0RT 


PROPAGATION_NOT_SUPP0RTED 




NEVER 


PR0PAGATI0N_NEVER 




NESTED 


PR0PAGATI0N_NESTED 





Une fois la transaction demarree, Spring impose de conserver une instance de son statut, 
materialisee par 1' interface TransactionStatus suivante : 

public interface TransactionStatus { 
boolean isNewTransaction( ) ; 
void setRol 1 backOnlyt ) ; 
boolean isRol 1 backOnly( ) ; 

} 

En plus des methodes de visualisation de proprietes de la transaction courante (methode 
isNewTransaction et isRollbackOnly), cette interface definit une methode setRol 1 backOnly, 
qui permet de specifier que la transaction doit etre annulee quels que soient les traitements 
ulterieurs. Ce mecanisme est semblable a celui des EJB, si ce n'est que, dans le cas de Spring, 
il est uniformise pour tous les types de transactions, locales comme globales, ou de ressources 
pour ce qui concerne les seules transactions locales. 

Lors de l'utilisation directe de l'API cliente de Spring, la gestion des exceptions et du 
comportement transactionnel est de la responsabilite de l'application, alors que, en cas d'utili- 
sation du template transactionnel, la levee d'une exception implique forcement, par defaut, 
une annulation de la transaction. 

Nous veiTons en detail l'utilisation de cette API a la section decrivant la facon de demarquer 
les transactions. 



Partie fournisseur de services 

La partie fournisseur de services de l'API generique est constituee par les implementations de 
l'interface PI atformTransactionManager. Spring les designe sous 1' appellation gestionnaire de 
transactions et foumit une multitude d' integrations avec differentes technologies et 
frameworks d'acces aux donnees, qui se fondent sur les ressources de la technologie ou du 
framework. 
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Les tableaux 11-8 a 11-11 recapitulent, technologie par technologie, ces implementations, 
lesquelles sont localisees dans les packages correspondant aux technologies ou frameworks 
utilises. 

Tableau 11-8. Implementation fondee sur JDBC 



Technologie 


Gestionnaire de transactions 


Ressource utilisee 


JDBC 


DataSourceTransactionManager 


DataSource 


Tableau 11-9. Implementations fondees sur des frameworks ORM 


Framework 


Gestionnaire de transactions 


Ressource utilisee 


Hibernate 3 


HibernateTransactionManager 


SessionFactory 


IBatis 


DataSourceTransactionManager 


DataSource 


J PA 


JpaTransactionManager 


Enti tyManager Factory 


JDO 


JdoTransactionManager 


Persi s ten ceManager Factory 


Tableau 11-10. Implementations fondees sur des middlewares 


Technologie 


Gestionnaire de transactions 


Ressource utilisee 


JMS 1.02 


JmsTransactionManagerl02 


ConnectionFactory (dans le cas de JMS 1 .02, il est 
necessaire de specifier le type de ressource, Queue 
ou Topic, avec la propriete pubSubDomain). 


JMS 1.1 


JmsTransactionManager 


ConnectionFactory 


JCA 


Cci LocalTransactionManager 


ConnectionFactory 


Tableau 11-11. Implementation fondee sur les transactions XA 


Technologie 


Gestionnaire de transactions 


Ressource utilisee 


XA 


JtaTransactionManager 


UserTransacti on, Transact ionManager 



Injection du gestionnaire de transactions 

Pour utiliser la gestion des transactions de Spring, le choix du gestionnaire de transactions est 
primordial. En fonction du type de demarcation utilise, ce gestionnaire n'est pas injecte sur les 
merries entires. 

Dans le cas de la demarcation par programmation, le composant service utilise ce gestionnaire 
directement ou via le template transactionnel. Le gestionnaire de transactions doit done etre 
injecte sur le composant. 

Cette injection est configuree dans le fichier de configuration XML applicationContext.xml 
localise dans le repertoire WEB-INF : 

<bean id="transactionManager" class="org.springframework 

.orm. jpa . JpaTransactionManager "> 
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<property name="enti tyManager Factory" 

ref=" entityManagerFactory"/> 

</bean> 



<bean id="todosManager" class="tudu. service. imp! .TodosManagerlmpl "> 
<property name="transactionManager" ref="transactionManager"/> 
</bean> 

Dans le cas de la demarcation declarative, cette responsabilite incombe desormais a Finter- 
cepteur transactionnel de Spring. Le gestionnaire doit done etre injecte sur l'intercepteur, 
lequel est configure en se fondant sur Fespace de nommage tx que nous decrivons par la 
suite : 

<bean id="transactionManager" class="org.springframework 

. orm. jpa . JpaTransactionManager"> 
<property name="enti tyManager Factory" 

ref=" entityManagerFactory"/> 

</bean> 

<tx: advi ce id="txAdvi ce" transact!' on -manager="transactionManager"> 
<tx:attributes> 
(...) 

</tx:attributes> 
</tx:advice> 

L' etude de cas Tudu Lists utilise cette approche afin de specifier les comportements transac- 
tionnels sur les composants. Linjection du gestionnaire de transactions se fait done de cette 
maniere avec une configuration fondee sur la POA. 



Gestion de la demarcation 

Maintenant que nous avons rappele les principes de la gestion des transactions avec Spring, 
nous pouvons detailler les differentes approches de gestion de la demarcation, par program- 
mation et par declaration. 

Gestion de la demarcation par programmation 

Spring offre deux facons de realiser cette demarcation. La premiere utilise directement les 
API generiques de Spring, dont Finterface principale est PlatformTransactionManager. La 
gestion des exceptions est a la charge du developpeur. La seconde utilise la classe 
TransactionTempl ate, le template de Spring dedie a la gestion des transactions fournissant une 
methode de rappel a implementer avec les traitements de la transaction. Dans ce cas, le deve- 
loppeur n'a qu'a se concentrer sur les traitements specifiques de F application. 

La definition des proprietes transactionnelles est effectuee grace aux implementations de 
Finterface TransactionDefinition. La plus communement utilisee est la classe Default- 
TransactionDefinition, mais il en existe d'autres, comme la classe Rul eBasedTransacti on- 
Attribute. Ces differentes implementations se trouvent toutes dans le package org. spring- 
framework, transaction, support. 
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Cette interface permet de specifier differentes constantes concernant la propagation transac- 
tionnelle et les niveaux d'isolation. Elle offre egalement des accesseurs sur le niveau d'isola- 
tion, le nom de la transaction, le type de propagation, le delai d' expiration, l'attribut lecture 
seule, etc. Cette interface a deja ete abordee a la section « Partie cliente » de ce chapitre. 

La definition des comportements face aux differentes exceptions ne peut etre configured avec 
cette approche. La responsabilite en incombe a 1' application, qui utilise directement les API 
transactionnelles de Spring. Nous verrons avec F approche declarative que Spring offre la 
possibility de configurer ce comportement et de rendre ainsi la demarcation des transactions 
particulierement flexible. 

Le code suivant illustre F utilisation des API generiques de Spring afin de realiser une demar- 
cation transactionnelle. Dans cet exemple, le gestionnaire de transactions (instance 
transacti onManager) de Spring est injecte a Faide des fonctionnalites dediees de Spring et est 
done disponible pour un composant de la couche service metier tel que F implementation 
TodosManagerlmpl (package tudu. service. impl) de Fetude de cas. Ce composant contient 
desormais le code suivant : 

Defaul tTransactionDefinition def 

= new DefaultTransactionDefinition( ) ;<— © 
def . setPropagationBehavior( 

Transacti onDefiniti on. PROPAGATION_REQUIRED) ;<-© 

TransactionStatus status 

= transactionManager.getTransaction(def ) ;<— © 

try { 

// Differents traitements metier de 1 'application ou 
// utilisation de composants d'acces aux donnees 
} catch (BusinessException ex) { 

transacti onManager . rol 1 back( status) ;<— © 
throw ex; 

} 

transacti onManager. commit (status) ;<— © 

Dans ce code, les proprietes et le comportement transactionnels des traitements sont d'abord 
specifies (©). Le debut de la transaction (©) est realise en s'appuyant sur le gestionnaire de 
transactions injecte avec Spring. La fin de la transaction peut etre realisee de deux manieres 
(©), toujours en s'appuyant sur le gestionnaire. 

Si tout se passe bien, la transaction est validee en se fondant sur la methode commi t tandis que, 
si une exception se produit, la transaction est annulee par la methode rol 1 back. 

Tous les traitements du bloc try/catch fondes sur la meme technologie que le gestionnaire 
sont automatiquement inclus dans la transaction. Si Fapproche d'enregistrement automatique 
dans le contexte transactionnel n'est pas utilisee, les composants d'acces aux donnees doivent 
necessairement utiliser les methodes utilitaires de Spring pour recuperer et relacher les 
connexions ou sessions. 
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Le code suivant illustre Futilisation du template transactionnel de Spring pour realiser une 
demarcation transactionnelle dans un composant de la couche service metier tel que l'imple- 
mentation TodosManagerlmpl (package tudu. service. impl) de l'etude de cas. Dans cet exem- 
ple, le gestionnaire de transactions (instance transact!' onManager) de Spring est egalement 
injecte a Faide de l'injection de dependances : 

TransactionTemplate template = new TransactionTempl ate( ) ; 
tempi ate .setTr ansa cti onManager (transact! onManager) ; 

Object result = tempi ate. execute(new TransactionCal 1 back( ) { 
public Object doInTransaction(TransactionStatus status) { 
// Differents traitements metier de 1 'application ou 
// utilisation de composants d'acces aux donnees 
return (...); 

} 

}); 

L'appel de la methode execute du template attend en parametre une implementation de Finter- 
face TransactionCal 1 back specifiant les traitements a realiser dans la transaction. En effet, la 
methode execute demarre tout d'abord une transaction en se fondant sur le gestionnaire speci- 
fic puis appelle la methode de rappel doInTransaction et valide ou annule la transaction 
suivant le resultat des traitements (exceptions non verifiees levees). 

Gestion de la demarcation par declaration 

La demarcation par declaration est a utiliser en priorite, car elle n'est pas intrusive pour le 
composant service metier. Le code technique des transactions est en effet externalise par 
rapport au code metier du composant. De plus, le comportement transactionnel peut etre 
specifie a F assemblage des composants en fonction des besoins. 

A cet effet, Spring met a disposition un espace de nommage dedie permettant de configurer simple- 
ment ces proprietes au niveau des methodes de classes. Spring configure alors un code advice tran- 
sactionnel, entite utilisable ensuite dans le contexte de la programmation orientee aspect. 

Lespace de nommage met a disposition respectivement les balises imbriquees advi ce, attri butes 
et method. C'est cette derniere balise qui permet de configurer les comportements transactionnels 
par methode en se fondant sur les proprietes recapitulees au tableau 11-12. 



Tableau 11-12. Attributs de la balise method de I'espace de nommage tx 



Attrbut 


Description 


propagation 


Specifie le comportement transactionnel souhaite pour l'appel de la methode (valeur par 
defaut REQUIRED). 


i sol ation 


Specifie le niveau d'isolation de la transaction (valeur par defaut DEFAULT). 


timeout 


Specifie le delai d'expiration de la transaction (valeur par defaut -1). 


read-only 


Active le mode lecture seule d'une transaction (valeur par defaut fal se). 


rol 1 back-for 


Specifie les exceptions permettant d'annuler une transaction lorsqu'elles surviennent. 
La levee d'exceptions non verifiees provoque toujours une annulation. 
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Tableau 11-12. Attributs de la balise method de I'espace de nommage tx (suite) 



Attrbut 


Description 


no-rollback-for 


Specifie les exceptions permettant de valider une transaction lorsqu'elles surviennent. La 
levee d'exceptions verifiees provoque toujours une validation. 


transaction- 


Reference le gestionnaire de transactions Spring a utiliser. 


manager 





Lorsque les attributs du tableau 11-12 ne sont pas precises au niveau de la balise method, les 
valeurs par defaut correspondantes sont utilisees. 

L'exemple suivant illustre la maniere de configurer I'espace de nommage tx (0) ainsi qu'un 
comportement transactionnel de type REQUIRED pour les methodes commencant par create, 
update, delete, add et restore (Q). Par - defaut, les methodes restantes sont configurees avec 
des transactions en lecture seule (©), mecanisme aborde dans la prochaine section : 

<beans xml ns="http: //www. spri ngframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns : aop="http : //www. spri ngf ramework. org/ schema /aop" 
xml ns : tx="http: //www. spri ngf ramework. org/schema/tx"<— © 
xsi :schemaLocation= 

"http: //www. spri ngframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd 

http: //www. spri ngframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop.xsd 

http: //www. spri ngf ramewo rk.org/schema /tx<— © 
http: //www. springframework.org/schema/tx/spri ng-tx.xsd"> 

(...) 

<bean id="transactionManager" cl ass=" ( . . . ) "> 

(...) 
</bean> 

<tx:advice id="txAdvice" 

transaction-manager="transactionManager"> 
<tx:attributes> 

<tx:method name="create*"/><— © 
<tx:method name-"update*"/><— Q 
<tx:method name="del ete*"/><— Q 
<tx:method name="add*"/><— Q 
<tx:method name="restore*"/><— Q 
<tx:method name="*" read-only="true"/><— Q 
</tx: attri butes> 
</tx:advice> 

<beans> 

Une fois, les comportements transactionnels definis, il convient de les appliquer sur les entites 
souhaitees en se fondant sur le support AOP de Spring, et plus particulierement I'espace de 
nommage aop. 
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Comme l'entite definie par la balise advice de l'espace de nommage tx correspond a un code 
advice Spring AOP et non Aspec J, il convient d'utiliser, comme dans le code suivant, la balise 
advi sor (0). Cette derniere permet de preciser une coupe au format AspectJ (Q) arm de defi- 
nir l'application des transactions tout en referencant le code advice transactionnel par l'inter- 
mediaire de l'attribut advice-ref (Q) : 

<aop:config> 

<aop:advisor<— Q 

pointcut="execiition(* *. .TodoListsManagerlmpl .*(..) )"<— Q 

advice-ref="txAd vice "/><—© 
</aop:config> 

Nous detaillons dans la suite de ce chapitre une implementation permettant de specifier des 
comportements transactionnels avec des annotations Java 5. 

Transactions en lecture seule 

Spring offre la possibilite de specifier des transactions d'un type particulier, dit en lecture 
seule. Cette denomination peut paraitre antinomique avec le concept meme de transactions 
puisque ces dernieres adressent notamment l'atomicite des mises a jour pour une ou plusieurs 
sources de donnees. 

Dans le contexte de Spring, une transaction en lecture seule offre la possibilite d'etendre la 
portee de la ressource permettant d'interagir avec une source de donnees dans le cadre de trai- 
tements de recuperation de donnees. 

Reprenons Fexemple de la section precedente. La specification de Fattribut read-only (Q) 
permet de preciser que, par defaut, une ressource devant acceder a la source de donnees est 
recuperee avant F execution de la methode et relachee apres. Les traitements dans la methode 
ne doivent cependant realiser que des lectures et aucune modification : 

<tx:advice i d="txAdvi ce"> 
<tx:attributes> 

<tx:method name="create*"/> 
<tx:method name="*" read-only="true"/><— Q 
</tx:attributes> 
</tx:advice> 

Cette facon de faire est uniformisee pour tous les supports d'acces aux donnees de Spring par 
Fintermediaire de son support transactionnel generique. Ce dernier permet notamment de resoudre 
les problematiques de chargement a la demande au sein d'une methode d'un service metier. 

La portee de la ressource d'acces a la source de donnees peut neanmoins s'averer insuffisante. 
C'est notamment le cas lorsque ce meme mecanisme de chargement a la demande est mis en 
ceuvre au niveau de la vue. Sans configuration additionnelle, la ressource est fermee a ce moment. 

Le patron de conception open-entity-manager-in-view doit alors etre utilise afin d'etendre 
encore la portee de la ressource et permettre sa fermeture apres la construction de la vue. 
Ce mecanisme est decrit au chapitre 7, dedie a Spring MVC. 
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Synchronisation des transactions 

Comme pour les EJB, Spring offre la possibilite a une classe d'etre notifiee a certains 
moments du cycle de vie de la transaction courante. II suffit pour cela d'utiliser Finterface 
TransactionSynchronization, arm de specifier 1' implementation de la synchronisation, et la 
classe TransactionSynchronizationManager, afin de l'enregistrer dans la transaction courante. 

Le code suivant en donne un exemple d' utilisation : 

TransactionSynchronizationManager. registerSynchronization( 
new TransactionSynchronization( ) { 
public void suspendO { } 
publ i c void resume( ) { } 

public void beforeCommit(boolean readonly) { 
Sy stem. out .printl n( "before commit" ) ; 

} 

public void beforeCompletion( ) { } 
public void afterCompletion(final int status) { 
Sy stem. out .printl n( "after compl etion" ) ; 

1 

1); 

Gestion des exceptions 

Spring offre un mecanisme interessant pour specifier la maniere de terminer une transaction 
lorsqu'une exception est levee. Le framework propose un comportement par defaut similaire 
a celui des EJB (validation pour les exceptions verifiees et annulation pour les exceptions non 
verifiees), mais qui peut aussi etre completement parametre en utilisant les attributs de la tran- 
saction. Ce mecanisme ne peut etre mis en ceuvre qu'avec l'approche de gestion des transactions 
par declaration. 

Si, par exemple, la levee d'une exception verifiee doit entrainer une annulation de la transaction, 
il suffit d'utiliser la configuration suivante en se fondant sur l'attribut rol 1 back-f or (Q) de la 
balise method : 

<tx: advice id="txAdvi ce"> 
<tx:attributes> 

<tx:method name="create*" 

rol 1 back- for=" Checked Except ion "/><—© 
<tx:method name="update*"/> 
<tx:method name="del ete*"/> 
<tx:method name="add*"/> 
<tx:method name="restore*"/> 
<tx:method name="*" read-only="true"/> 
</tx:attributes> 
</tx:advice> 

En cas de validation d'une transaction sur la levee d'une exception, c'est la balise no- 
roll back-for qui doit etre utilisee. 
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Fonctionnalites avancees 

Spring fournit quelques fonctionnalites interessantes facilitant et allegeant la mise en 
ceuvre des transactions dans une application Java/Java EE, comme 1' utilisation transpa- 
rente du contexte transactionnel, 1' heritage des configurations transactionnelles ou les 
annotations. 



Utilisation transparente du contexte transactionnel 

Spring est devenu maitre dans l'art d'integrer des frameworks tiers dans une application de 
la maniere la plus optimale et modulaire possible. II fournit egalement un mecanisme inte- 
ressant pour ajouter un composant dans un contexte transactionnel gere par Spring de 
maniere transparente, le composant n'ayant pas forcement besoin d' avoir ete developpe 
avec Spring. 

Spring fournit ces types de proxy sur les ressources transactionnelles pour differentes techno- 
logies. Ces proxy ont par convention un nom commencant par TransactionAware. lis integrent 
automatiquement les connexions ou sessions dans le contexte transactionnel de Spring, si bien 
que les composants peuvent ne plus utiliser les classes utilitaires de Spring pour recuperer et 
relacher ces ressources. 

Le code suivant montre comment configurer ce mecanisme avec JDBC (cette mise en ceuvre 
ne depend pas de 1' implementation de l'interface DataSource choisie) : 

<bean id="dataSourceTarget" class-"org.springframework. jdbc. 

datasource. Dri verManagerDataSource"> 
<property name="driverCl assName" 

val ue="org.hsqldb. jdbcDriver"/> 
<property name="url" 

val ue=" jdbc : hsql db : hsql : //local host: 9001"/> 
<property name="username" val ue-"sa"/> 
<property name="password" value=""/> 
</bean> 

<bean id="dataSource" class="org.springframework.jdbc. 

datasource .Trans act ion AwareDataSourceProxy"> 
<property name="dataSource" ref="dataSourceTarget"/> 
</bean> 

Les annotations 

Spring offre la possibilite de definir les comportements transactionnels des composants grace 
a des annotations Java 5. Ce mecanisme permet d'alleger le fichier XML de configuration de 
Spring et de specifier le comportement transactionnel aussi bien au niveau du contrat du 
composant que de 1' implementation. 

II est toutefois preferable de les definir au niveau du contrat du composant, les implementa- 
tions correspondantes etant automatiquement impactees. Les implementations ainsi que leurs 
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differentes methodes heritent done de ce comportement par defaut, mais peuvent le surcharger 
au cas par cas si necessaire. 

II est egalement a noter que les comportements specifies au niveau des classes ou des inter- 
faces sont automatiquement appliques aux methodes contenues. Chaque methode a la 
possibilite de modifier ce comportement en precisant de nouvelles annotations a son 
niveau. 

Les types de comportements sont ajoutes dans les services metier (interface ou implementa- 
tion) grace a l'annotation Transactional, dont le tableau 11-13 recapitule les differentes 
proprietes possibles. 



Tableau 11-13. Proprietes de l'annotation Transactional 



Propriete 


Type 


Description 


Propagation 


enum: Propagati on 


Specifie le type de propagation de la tran- 
saction (valeur par defaut PROPAGATION. 
REQUIRED). 


Isolation 


enum: I sol ation 


Specifie le niveau d'isolation de la transac- 
tion (valeur par defaut ISOLATION. 
DEFAULT). 


Readonly 


bool ean 


Specifie si la transaction est en lecture 
seule (valeur par defaut f al se). 


Rol 1 backFor 


Tableau d'objets de type Class 


Specifie la liste des exceptions qui cause- 
ront une annulation de la transaction. 


Rol 1 backForCl assname 


Tableau d'objets de type String 


Specifie la liste des noms des exceptions 
qui causeront une annulation de la tran- 
saction. 


NoRol 1 backFor 


Tableau d'objets de type Class 


Specifie la liste des exceptions qui ne cau- 
seront pas d'annulation de la transaction. 


NoRoll backForCl assname 


Tableau d'objets de type String 


Specifie la liste des noms des exceptions 
qui ne causeront pas d'annulation de la 
transaction. 



Le code suivant donne un exemple de mise en ceuvre de l'annotation Transactional (©) sur 
l'interface TodoListsManager : 

©Transactional ( readOnly=true)<— © 
public interface TodoListsManager { 

©Transactional (readonly = false, <— © 

propagation = Propagation. REQUIRED) 
void createTodoLi st(TodoLi st todoList); 

TodoList findTodoList(String listld); 

©Transactional (readonly = false, © 

propagation = Propagation. REQUIRED) 
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void updateTodoListdodoList todoList); 
(...) 

} 

Les annotations permettant de specifier des comportements trans actionnels au sein meme des 
classes de services, il n'est plus necessaire d' avoir recours a la programmation orientee aspect 
pour les appliquer reellement. II suffit d'activer cette approche grace a la balise annotation- 
dri ven de l'espace de nommage tx. II convient neanmoins de specifier le gestionnaire de tran- 
sactions de Spring utilise au moyen de Fattribut transaction-manager. 

Le code suivant illustre la mise en ceuvre de cette balise et de cet attribut afin d'activer la 
configuration des transactions fondee sur les annotations : 

<tx: annotation -driven transaction-manager="transactionManager"/> 



Approches personnalisees 

Les approches decrites precedemment peuvent ne pas convenir completement a une applica- 
tion en raison de leur integration a d'autres composants ou frameworks utilises dans 1' archi- 
tecture. 

D'une maniere generate, le support standard des transactions de Spring suffit largement. 
Cependant, il peut se reveler utile de combiner plusieurs technologies pour en tirer le meilleur 
parti, notamment dans les cas suivants : 

• Le besoin d'uniformiser la demarcation transactionnelle conduit a utiliser une API gene- 
rique. Spring fournit ce type d'API, mais elle peut etre utilisee sans pour autant recourir a 
l'injection de dependances implemented dans Spring. 

• Le souci de modularite des composants amene a vouloir externaliser les problematiques 
techniques induites par les transactions. Lutilisation de technologies d' interception des 
traitements telles que la POA permet d'atteindre ce but. Le type de tisseur POA peut etre 
choisi en fonction des besoins de F application et ne pas etre celui de Spring. 

• La specification de comportements trans actionnels plus fins pour les composants transac- 
tionnels peut etre realisee a F assemblage ou au deploiement de maniere declarative afin 
d'offrir encore plus de flexibilite. La combinaison de technologies telles que les EJB ou 
Spring permet d'offrir cette fonctionnalite. 

II est done possible de combiner Spring avec d'autres technologies ou frameworks afin de 
repondre au plus pres aux besoins de F application, notamment les technologies EJB et POA. 

Combinaison des technologies EJB et Spring 

Dans la communaute Java EE, il est parfois de bon ton de mettre en concurrence la technolo- 
gie EJB et le framework Spring. Les auteurs de cet ouvrage estiment pour leur part que les 
deux peuvent etre utilises de maniere complementaire, car ils ne couvrent pas completement 
les memes domaines. 
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Comme un contexte applicatif de Spring peut etre embarque dans un EJB Session, il est possi- 
ble d'obtenir un niveau de granularite plus fin dans celui-ci. Cela apporte en outre des avantages 
en termes de gestion des transactions. 

Si une CMT (Container Managed Transaction) est utilisee, les transactions des EJB seront 
gerees par le conteneur. Un contexte applicatif de Spring peut etre embarque dans un EJB ann 
de gerer plus finement les comportements transactionnels des differents composants utilises 
par l'EJB. Comme, dans ce cas, JTA est utilise, le gestionnaire de transactions JtaTransac- 
tionManager de Spring doit etre utilise. 

Si une BMT (Bean Managed Transaction) est utilisee, les transactions peuvent etre gerees de 
la maniere souhaitee dans Spring, qui les controle completement. 

Combiner Spring et AspectJ 

L' application peut ne pas vouloir utiliser le tisseur POA de Spring et choisir un tisseur statique 
tel qu' AspectJ. II est possible en ce cas de developper un aspect AspectJ utilisant les API de 
gestion transactionnelle de Spring. II est a noter qu' AspectJ fournit non pas un mecanisme de 
gestion transactionnelle, mais un cadre propice a sa mise en place. 

Spring offre une integration avec AspectJ permettant de realiser de l'injection de depen- 
dances de composants tiers sur un aspect de type singleton. Dans notre cas, le gestionnaire 
de transactions ainsi que les comportements transactionnels desires pour les composants 
tisses peuvent etre injectes dans 1' aspect. Le code advice de 1' aspect a des lors la res- 
ponsabilite d' utiliser les API de Spring et de definir les coupes sur les composants transac- 
tionnels. 

Comme Spring a en charge la gestion du contexte transactionnel, 1' aspect peut etre de type 
singleton, ce framework le stockant dans un Thread Local. 



En resume 

Spring offre un mecanisme de gestion des transactions particulierement flexible, qui permet 
de repondre au mieux aux exigences des applications. Ce framework fournit en outre un 
mecanisme de gestion des transactions declaratif independant des conteneurs Java EE, aussi 
bien pour les transactions locales que globales. 

De ce fait, Spring n'impose pas l'utilisation du service transactionnel du serveur d'applica- 
tions, lequel s'appuie sur les transactions globales, sans l'interdire pour autant. II est done 
possible de l'utiliser a bon escient. 

Spring permet d'externaliser la gestion des transactions des composants. Ces derniers n'ont de 
la sorte pas conscience de la strategie transactionnelle qui va etre utilisee. Celle-ci est realisee 
lors de F assemblage des composants dans les fichiers de configuration. Les composants sont 
de la sorte de plus en plus decouples des technologies et frameworks sous-jacents. Utiliser 
directement leurs API constituerait une bien mauvaise pratique puisque les composants 
seraient alors fortement lies a la technologie et done tres difficiles a faire evoluer. 
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Le tableau 11-14 recapitule les avantages et inconvenients de Spring et des EJB pour la 
gestion des transactions. 

Tableau 11-14. Avantages et inconvenients de Spring et des EJB pour la gestion tran- 



sactionnelle 


Technologie 


Avantages 


Inconvenients 


EJB 


- Gestion des transactions au niveau des com- 
posants 

- Choix du niveau d'intrusivite de la mise en 
ceuvre (par programmation ou declarative) 


- Serveur d'applications Java EE avec un con- 
teneur d'EJB necessaire 

- Utilisation des transactions globales obliga- 
toire dans le cas d'une gestion par le conteneur 

- Solution peu flexible 


Spring 


- Gestion des transactions au niveau des com- 
posants 

-Choix du niveau d'intrusivite de la mise en 
ceuvre (par programmation ou declarative) 

- Solution tres flexible quant aux types de tran- 
sactions, a leur configuration et a la gestion 
des exceptions 

- Utilisation possible en dehors d'un serveur 
d'applications 


- Complexite deportee au niveau du fichier de 
configuration du conteneur leger 

- Notions de POA souhaitables 



Mise en oeuvre de la gestion des transactions dansTudu Lists 

Dans l'etude de cas Tudu Lists, nous specifions les comportements transactionnels par decla- 
ration en nous appuyant sur les mecanismes transactionnels de Spring et Fapproche utilisant 
Fannotation Transactional . 

Comme F application utilise JPA pour interagir avec la base de donnees, nous mettons en 
ceuvre la classe JpaTransactionManager du package org.springframework.orm. jpa, implemen- 
tation de Finterface PI atformTransactionManager pour JPA. 

Comme Fillustre le code suivant, cette classe s'appuie sur Finstance de 1'EntityManager- 
Factory configuree, tiree du fichier dedie a la configuration des transactions : 

<tx: annotation -dri ven t r ansa ct ion -man ager=" trans act i onManager"/> 

<bean id="transactionManager" class="org. spring-framework 

.orm.jpa . JpaTransactionManager "> 
<property name="enti tyManager Factory" 
ref="enti tyManager Facto ry"/> 

</bean> 

La configuration ci-dessus utilise la balise annotation-driven afin de se fonder sur Fannota- 
tion Transactional pour determiner les comportements transactionnels des composants. 

Ces comportements, qui doivent etre specifies pour tous les composants service metier de 
l'etude de cas, sont recapitules au tableau 1 1-15. 
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Tableau 11-15. Composants services metier de l etude de cas 



Composant 


Comportement transactionnel 




userManager 


- Methode create : REQUIRED 
-Methode update : REQUIRED 
-Methode delete : REQUIRED 

- Autres methodes : REQUIRED et readonly 




todoLi stsManager 


-Methode create : REQUIRED 

- Methode update : REQUIRED 
-Methode delete : REQUIRED 
-Methode add : REQUIRED 

- Methode restore : REQUIRED 

-Autres methodes : PROPAGATION_REQUIRED et readonly 




todosManager 


- Methode create : PROPAGATION_REQUI RED 
-Methode update : PROPAGATION_REQUIRED 
-Methode delete : PROPAGATION_REQUIRED 
-Methode completeTodo : PROPAGATION_REQUIRED 

- Methode reopenTodo : PROPAGATION_REQUIRED 
-Autres methodes : PROPAGATION_REQUIRED et readonly 




conf igurationManager 


- Methode update : PROPAGATION_REQUIRED 

-Autres methodes : PROPAGATION_REQUIRED et readonly 





Le code suivant illustre un exemple de configuration des comportements transactionnels 
fonde sur l'annotation Transactional (0) dans la classe TodoLi stsManagerlmpl : 

©Transact!' onal<— © 

public class TodoListsManagerlmpl implements TodoLi stsManager { 
(...) 



public void createTodoList(final TodoList todoList) { 
(...) 

} 

©Transactional (readonly = true)<— Q 
public TodoList findTodoList(String listld) { 
(...) 

} 

©Transactional (readonly = true)<— Q 
public TodoList unsecuredFindTodoList(String listld) { 
(...) 

} 

public void updateTodoListtfinal TodoList todoList) { 
(...) 

} 
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Conclusion 

La gestion des transactions est une des problematiques les plus importantes et les plus 
complexes a mettre en ceuvre dans une application. Elle peut impliquer plusieurs ressources 
transactionnelles fondees sur des technologies differentes, avoir a prendre en compte des 
acces concourants et savoir reagir aux erreurs ou aux pannes afin de garantir la coherence des 
donnees. La mise en place de ces mecanismes au sein des applications est indispensable afin 
de garantir leur robustesse. 

Les types de transactions utilises doivent etre adaptes aux besoins de F application. Par exem- 
ple, F utilisation de transactions globales peut amener une complexite inutile si une seule 
ressource transactionnelle est utilisee. Des frameworks tels que Spring fournissent desormais 
des mecanismes permettant de gerer les transactions locales de maniere declarative. 

La mise en place des transactions dans les applications ne doit pas etre negligee, car il s'agit 
d'une problematique de conception a part entiere. Les differents concepts propres aux transac- 
tions decrits dans ce chapitre doivent etre appliques aux bons composants et les polluer le 
moins possible avec du code technique. Cette mise en place ne doit pas non plus etre realisee 
au detriment de la modularite ni de la flexibilite de l'architecture applicative. 

Lutilisation de mecanismes declaratifs pour specifier les comportements transactionnels doit 
etre privilegiee, de meme que le choix de frameworks ou de technologies offrant cette fonc- 
tionnalite. 



12 

Support des technologies 

JMS et JCA 



Les applications Java/Java EE doivent s'integrer dans les systemes d'information des 
entreprises, ou EIS (Enterprise Information System), qui component differentes applica- 
tions et infrastructures de stockage des donnees. Elles doivent pouvoir reutiliser des 
services applicatifs existants, tout en minimisant les duplications de donnees dans ces 
differents systemes. 

L' interaction entre des applications pouvant etre separees physiquement au sein de 
l'entreprise et utilisant des mecanismes ou des technologies heterogenes peut vite devenir 
complexe, puisqu'il n'est pas toujours possible de les reecrire ou de les modifier. Or cette 
reecriture n'est pas forcement la meilleure solution pour des applications repondant aux 
besoins et fonctionnant correctement. L'interaction avec elles est la solution la plus 
appropriee. 

Cette interaction peut s'inserer dans differents types de traitements et mettre en ceuvre des 
mecanismes de communication complexes, synchrones ou asynchrones. Ce chapitre se 
penche sur les technologies et mecanismes foumis par Java EE afin d'integrer des applications 
dans des systemes d'information d'entreprise par le biais des specifications JMS (Java Messaging 
Service) et JCA (Java Connector Architecture). 
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La figure 12-1 schematise ces echanges. 



Figure 12-1 

Interactions entre les 
applications Java/Java EE 
et les applications 
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Nous verrons que Spring fournit des supports pour ces deux technologies afin d'alleger leur 
mise en ceuvre et leur integration au sein des applications Java/Java EE. 

Les sections qui suivent detaillent les differentes technologies permettant aux applications 
Java/Java EE de s'integrer aux applications d'entreprise, ainsi que les supports de Spring 
simplifiant leur utilisation. 

Nous commencons par presenter la technologie JMS, afin de mieux apprehender son support 
par Spring. Nous utilisons ensuite la meme approche pour la technologie JCA. 



La specification JMS (Java Messaging Service) 

La specification JMS vise a resoudre les preoccupations generates des messageries applicatives 
avec Java. 

JMS adresse la problematique generate des MOM (Message-Oriented Middleware), ou 
middlewares orientes messages, en Java. Ces outils permettent en effet de faire communiquer 
des applications par F intermediate de messages applicatifs contenant diverses informations 
applicatives ou de routage reseau. 

Ces systemes garantissent la distribution des messages aux applications, tout en fournissant 
des fonctionnalites de tolerance aux pannes, d'equilibrage de charge, d'evolutivite et de 
support transactionnel. lis utilisent a cet effet des canaux de communication, designes par le 
terme destination, qui peuvent etre utilises afin de mettre en ceuvre des mecanismes de 
communication asynchrones. 

La specification JMS adressant la messagerie applicative fournit un cadre generique pour 
envoyer et recevoir des messages de maniere synchrone et asynchrone. Elle fournit de surcroit 
un niveau d' abstraction normalise afin d'interagir avec differents systemes de messagerie 
applicative, la plupart d' entre eux supportant desormais cette specification. On designe les 
systemes de messagerie applicative compatibles JMS par les termes fournisseurs JMS. 
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Les fournisseurs JMS 

Chaque fabricant JMS propose une implementation de I'API JMS cliente permettant d'interagir avec le 
serveur JMS. Le fabricant JMS offre egalement un module serveur de gestion de messages, qui imple- 
mente le routage et la distribution des messages. Ces deux entit.es sont collectivement designees par le 
terme fournisseur JMS. Quelle que soit ('architecture utilisee par un fournisseur JMS, les parties logiques 
d'un systeme JMS sont identiques. Un fournisseur JMS correspond done a un middleware ayant la respon- 
sabilite de recevoir et de distribuer les messages applicatifs. II implements a cet effet des mecanismes 
complexes, qui garantissent I'envoi et la reception de ces messages. 



JMS distingue deux domaines de messagerie. Le premier, appele file, ou queue, correspond a 
une distribution point-a-point. Un message envoye sur un domaine de ce type est distribue une 
seule fois et a un seul observateur enregistre, comme l'illustre la figure 12-2. 
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Figure 12-2 

Mecanisme de distribution des messages pour le domaine file 

Le second domaine, appele sujet, ou topic, fonctionne sur le principe des listes de diffusion. 
Tous les observateurs enregistres sur le domaine recoivent le message envoye, comme l'illustre 
la figure 12-3. 
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Figure 12-3 

Mecanisme de distribution des messages pour le domaine sujet 
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Notons qu'une file ou un sujet est communement designe dans la technologie JMS par le 
terme destination. Ces entites sont representees par les interfaces Queue et Topic, heritant 
toutes deux de 1' interface Destination du package javax. jms. 

La specification JMS comporte deux versions majeures. La version 1.0.2, la plus ancienne, 
dissocie dans ses API les deux domaines de messagerie. Elle comporte toutefois des limita- 
tions, notamment pour la gestion transactionnelle des messages. La version 1.1 adresse ces 
problemes en uniformisant et homogeneisant les differentes API. Dans la suite du chapitre, 
nous nous fondons sur cette version 1.1, qui est couramment utilisee dans les applications 
d'entreprise Java/Java EE. 



Interaction avec le fournisseur JMS 

L interaction avec le fournisseur JMS se realise en plusieurs etapes : 

1. Creation de la fabrique de connexions. 

2. Recuperation d'une connexion a partir de la fabrique precedente. II est possible de 
specifier des proprietes pour la connexion, telles que l'identifiant du client. 

3. Creation d'une session a partir de la connexion. Au moment de cette creation, il est 
possible de definir des proprietes transactionnelles, ainsi que le type d'acquittement 
d'envoi des messages. 

La fabrique de connexion JMS est normalisee par l'intermediaire de Finterface Connection- 
Factory du package javax. jms. Son unique fonction est de creer des connexions pour un four- 
nisseur JMS, comme le montre son code ci-dessous : 

public interface ConnectionFactory { 
Connection createConnection( ) ; 

Connection createConnection(String userName, String password); 

La connexion JMS correspond a la connexion physique avec le fournisseur JMS. Cette entite 
est normalisee par l'intermediaire de Finterface Connection du package javax. jms. Sa creation 
necessite une authentification de la pail de Futilisateur. Elle offre la possibilite de creer une 
session d'utilisation permettant d'envoyer et de recevoir des messages, ainsi que de creer 
differents types de messages. 

II est possible de positionner un identifiant pour la connexion par l'intermediaire de sa 
methode setCl ientlD. Le code suivant donne la definition de cette entite : 

public interface Connection { 
void closet); 
(...) 

Session createSession(boolean transacted, int acknowl edgeMode) ; 
String getCl ientID( ) ; 

Excepti on Li stener get Except i onl_istener( ) ; 
ConnectionMetaData getMetaData( ) ; 
void setCl ientID(String clientID); 

void setExceptionl_istener(Exceptionl_istener listener); 
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void startO; 
void stopO; 

I > 

Notons la presence de l'interface ExceptionListener et de la methode setExceptionListener 
de l'interface Connection, qui permettent d'enregistrer des observateurs et de recuperer les 
exceptions survenant lors de F utilisation de la connexion. 

Lorsqu'une connexion est creee, elle se retrouve en mode non actif et ne peut done recevoir de 
messages. II est par contre possible d'envoyer des messages par Fintermediaire de Fentite 
MessageProducer, que nous decrivons plus loin dans ce chapitre. 

Les methodes start et stop de l'interface precedente permettent de changer ce mode. Une fois 
la methode start invoquee, l'application peut utiliser Fentite MessageConsumer, que nous 
decrivons egalement plus loin, afin de recevoir des messages. La methode cl ose permet quant 
a elle de fermer la connexion avec le fournisseur JMS. 

Notons qu'une connexion JMS est thread safe et que plusieurs fils d'execution peuvent done utili- 
ser la meme connexion simultanement, ce qui n'est pas le cas de la session decrite par la suite. 

La session JMS permet d'interagir directement avec le fournisseur JMS afin d'envoyer, de 
recevoir et de creer des messages. Cette entite est normalisee par l'interface Session du 
package javax. jms. Au moment de sa creation, Futilisateur peut specifier si elle doit etre tran- 
sactionnelle ainsi que le type d'acquittement des messages. Le code suivant donne la definition 
de cette entite : 

public interface Session { 
(...) 

//Creation de consommateur de messages 

MessageConsumer createConsumer(Destination destination); 

MessageConsumer createConsumer(Destination destination, 

String messageSelector) ; 
MessageConsumer createConsumer(Destination destination, 

String messageSelector, boolean NoLocal); 

//Gestion des souscriptions durables 
Topi cSubscriber createDurabl eSubscriber( 

Topic topic, String name); 
TopicSubscriber createDurableSubscriber(Topic topic, 

String name, String messageSelector, boolean noLocal); 
void unsubscribe(String name); 

//Creation de producteur de messages 

MessageProducer createProducer(Destination destination); 

//Creation de destinations 
Topic createTopic(String topicName) ; 
Queue createQueue(String queueName) ; 
Temporary Topi c createTemporaryTopic( ) ; 
TemporaryQueue createTemporaryQueue( ) ; 

//Creation de messages 
TextMessage createTextMessage( ) ; 
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TextMessage createTextMessage(String text); 

Message createMessage( ) ; 

ObjectMessage createObjectMessage( ) ; 

ObjectMessage createObjectMessage(Serializable object); 

BytesMessage createBytesMessage( ) ; 

MapMessage createMapMessaget ) ; 

StreamMessage createStreamMessage( ) ; 

//Proprietes de la session 
int getAcknowl edgeMode( ) ; 
boolean getTransacted( ) ; 

//Observateurs enregistres 

MessageListener getMessageLi stener( ) ; 

void setMessageLi stener(MessageLi stener listener); 

//Gestion des transactions 
void commitO; 
void recoverO; 
void rollbackO; 

//Gestion de la session 

void closeO; 

(...) 

} 

Dans la definition de l'interface precedente, nous remarquons plusieurs types de methodes. 
Ces dernieres correspondent aux fonctionnalites recapitulees au tableau 12-1. 



Tableau 12-1. Fonctionnalites de la session JMS 



Fonctionnalite 


Description 


Envoi de messages 


Cree les entites necessaires a I'envoi de messages. 


Reception de messages 


Cree les entites necessaires a la reception de messages. 


Gestion des souscriptions durables 


Fournit des methodes afin de gerer les souscriptions durables a des sujets. Ces der- 
nieres permettent a un utilisateur de recevoir tous les messages JMS, y compris ceux 
publies pendant une periode oil celui-ci est inactif. 


Creation de destinations 


Cree des destinations (file ou sujet) en dehors des outils d'administration du fournisseur. 


Creation de messages JMS 


Offre plusieurs methodes permettant de creer les differents types de messages sup- 
poses par la specification. Leur nom suit la regie create<TYPE>Message( ). 


Proprietes de la session 


Recupere les valeurs des proprietes transacted et acknowl edgeMode correspon- 
dent respectivement aux proprietes transactionnelles et d'acquittement. 


Enregistrement d'un observateur JMS 


Permet I'enregistrement d'un observateur JMS afin de recevoir et de traiter les mes- 
sages par I'intermediaire de la methode setLi stener. 


Gestion des transactions 


Offre deux methodes afin de finaliser une transaction JMS : commi t en cas de succes 
et rol 1 back en cas d'annulation. 


Gestion de la session 


La methode cl ose permet de fermer la session JMS. 
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Le code suivant met en ceuvre ces differentes entites afin d'interagir avec un fournisseur JMS : 

Connecti onFactory connectionFactory=nul 1 ; 
Connection connecti on=null ; 
Session session=nul 1 ; 

try { 

connectionFactory=getConnectionFactory( ) ; 
connecti on=connecti onFactory .createConnect ion ( ) ; 
connection. start( ) ; 

boolean transacted=false; 

1nt acknowledgeMode=Session.AUTO_ACKNOWLEDGE; 

session=connection.createSession(transacted,acknowledgeMode) ; 
} catch(Exception ex) { 

convertJmsException(ex) ; 
} finally { 

closeSess ion (session) ; 

stopAndCl oseConnecti on (connecti on) ; 



Constituants d'un message JMS 

Avant d'envoyer des informations au fournisseur JMS, il faut determiner le type de message 
puis le creer. Un message JMS est structure comme decrit au tableau 12-2. 



Constituant 

En -fete 



Proprietes 
Corps 



Tableau 12-2. Constituants d'un message JMS 



Description 

Specifie des informations interpretables aussi bien par le client que par le fournisseur afin de defi- 
nir le message et de I'acheminer. La plupart de ces en-fetes (JMSDesti nation, JMSDel i very- 
Mode, JMSExpi rati on, JMSPriority, JMSMessagelD, JMSTimestamp) sont positionnes 
automatiquement par les methodes send ou publish de la session JMS.Seuls les en-fetes JMS- 
Correl ationID, JMSReplyTo et JMSType peuvent etre utilises par I'application cliente. 

Specifie des informations applicatives dans le message. 

Contient les donnees specifiques de I'application. Elles peuvent prendre differentes formes au 
sein de cette partie. 



JMS definit les differents types de messages recapitules au tableau 12-3. 

Tableau 12-3. Types de messages JMS 



Type 

StreamMessage 
MapMessage 



Description 

Permet de stacker sequentiellement des informations de type primitif dans le message. Cette 
interface etend I'interface Message afin de fournir des methodes de lecture etd'ecriture de don- 
nees par type. 

Permet de stacker les informations du message sous forme de table de hachage. Cette inter- 
face etend I'interface Message afin de fournir les methodes permettant d'acceder aux differents 
elements suivant leurs types. 
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Tableau 12-3. Types de messages JMS (suite) 



Type 


Description 


TextMessage 


Permet de stacker des informations de type texte, aussi bien texte simple que XML, dans un 
message JMS. Cette interface etend I'interface Message afin de fournir des methodes getText 
et setText pour acceder au texte du message et le specifier. 


ObjectMessage 


Permet de stacker un objet Java serialisable dans un message JMS. Cette interface etend 
I'interface Message afin de fournir des methodes getObject et setObject pour acceder a 
I'objet du message et le specifier. 


BytesMessage 


Permet de stacker un tableau d'octets dans un message JMS. Cette interface etend I'interface 
Message afin de fournir des methodes pour lire et ecrire des octets. 



La creation des messages se realise a partir d'une instance de la session courante, comme ici : 

Session session = createSession(connection) ; 

//Creation d'un message de type texte 

TextMessage txtMessage = session. createTextMessage( ) ; 

message. setTextC'Le texte de mon message"); 

(...) 

//Creation d'un message de type Map 
MapMessage mapMessage = sessi on. createMapMessage( ) ; 
mapMessage.setStringCdescription", "Description de mon message"); 
mapMessage. set I nt( "tai 1 1 e" ,26) ; 

II est egalement possible de positionner des en-tetes et des parametres sur le message : 

txtMessage. set JMSCorrel ationID( "mon Id" ) ; 

txtMessage. setStringProperty( "ma Propriete" , "maVal eur" ) ; 



Envoi de messages 

L'entite cle pour envoyer des messages avec JMS est I'interface MessageProducer du package 
javax. jms, dont le code est le suivant : 

public interface MessageProducer { 
void closeO; 
int getDel i veryMode( ) ; 
Destination getDestination( ) ; 
boolean getDisabl eMessagelDt ) ; 
boolean getDisableMessageTimestamp( ) ; 
int getPriority( ) ; 
long getTimeToLive( ) ; 

void send(Destination destination, Message message) ; 
void send(Destination destination. Message message, 

int del iveryMode, int priority, long timeToLive); 
void send(Message message) ; 
void send(Message message, int del iveryMode, 

int priority, long timeToLive); 
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void setDeliveryModeO'nt del iveryMode) ; 

void setDi sabl eMessageID(bool ean value); 

void setDi sabl eMessageTimestamp(bool ean value); 

void setPrioritydnt defaultPriority) ; 

void setTimeToLivedong timeToLive) ; 

} 

Une entite MessageProducer possede les proprietes decrites au tableau 12-4. 



Tableau 12-4. Proprietes de I'entite MessageProducer 



Propriete 


Description 


destination 


Destination (file ou sujet) sur laquelle le message doit etre envoye. 


del i veryMode 


Mode de distribution du message. Les valeurs possibles sont Del i veryMode . NON_PERSIS- 
TENT et Del i veryMode. PERSISTENT. Le mode persistant garantit une distribution du mes- 
sage, meme en cas de panne du fournisseur JMS, ce qui n'est pas le cas en mode non 
persistant. 


di sabl eMessagelD 


Deactivation de la generation d'identifiant de messages par le fournisseur JMS 


disabl eMessageTimestamp 


Deactivation du calcul de I'estampille temporelle par le client JMS 


priority 


Priorite du message 


timeToLi ve 


Date d'expiration du message 



Toutes ces proprietes peuvent etre specifiees de maniere globale au moment de la creation du 
MessageProducer. Comme le montre le code suivant, les valeurs specifiees au niveau du 
producteur (Q) sont utilisees lors de l'envoi (Q) des messages : 

(...) 

Session session = createSession(connection) ; 
Destination destination - getDestinationt ) ; 
TextMessage message = session. createTextMessage( ) ; 
message. setText( "texte du message"); 
MessageProducer messageProducer 

= session. createProducer(destination) ; 
messageProducer. set Del i veryMode ( Message. DEFAULT_DELIVERY_MODE) ;<— © 
messageProducer. setPriority( Message. DEFAULTPRIORITY) ;<— O 
messageProducer . setTimeToLi ve( Message . DEFAULT_TIME_TO_LIVE) ;<— O 
messageProducer .send (message) ;<— Q 
mess age Producer. cl ose( ) ; 

II est possible de definir des valeurs specifiques pour un message lors de son envoi. Ces 
dernieres, precisees par Fintermediaire de la methode send (Q), remplacent les valeurs definies 
au niveau du MessageProducer : 

(...) 

Session session = createSession(connection) ; 
Destination destination = getDestinationt ) ; 
TextMessage message = session. createTextMessage( ) ; 
message . setText( "texte du message"); 
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MessageProducer messageProducer 

= session. createProducer(destination) ; 
messageProducer. send (mess age, Message.DEFAULT_DELIVERY_MODE,<— Q 

Message. DEFAULT_PRI0RITY.<-O 
Message. DEFAULT_TIME_TO_LIVE) ;<-© 

messageProducer.close( ) ; 

Reception de message 

L'entite cle pour recevoir des messages avec JMS est l'interface MessageConsumer du package 
javax. jms, dont le code est le suivant : 

: public interface MessageConsumer { 
void closeO; 

MessageListener getMessageLi stener( ) ; 
String getMessageSel ector( ) ; 
Message receiveO; 
Message receivedong timeout); 
Message receiveNoWait( ) ; 

void setMessageLi stener(Messagel_i stener listener); 

} 

Cette interface offre la possibilite de recevoir des messages JMS de maniere synchrone, et 
done la plupart du temps bloquante, par l'intermediaire de ses differentes methodes receive. 

Ces methodes permettent de se mettre en attente d'un message indefrniment, durant un temps 
fini ou non bloquant. Dans ce dernier cas, la methode renvoie null si aucun message n'est 
disponible au moment de son execution. Le code suivant en donne un exemple d' utilisation : 

(...) 

Session session = createSession(connection) ; 
Destination destination=getDesti nation( ) ; 

MessageConsumer messageConsumer 

= ses s i on. createConsumer( destination) ; 

int timeout - 60; 

Message message = messageConsumer. receive(timeout) ; 
messageConsumer. closet ) ; 

Lorsque l'entite MessageConsumer est utilisee conjointement avec l'interface MessageListener, 
elle permet de recevoir des messages JMS de maniere asynchrone. Dans ce cas, lors de la 
reception d'un message, la methode onMessage de l'observateur est appelee, avec le message 
en parametre. 

Le code suivant decrit l'interface MessageListener du package javax. jms : 

I public interface MessageListener { 
void onMessage(Message message); 
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Voici un exemple de mise en ceuvre de reception asynchrone de message avec JMS : 
(...) 

Session session = createSession(connection) ; 
Desti nation destination=getDesti nation ( ) ; 

MessageConsumer messageConsumer 

= session . createConsumer( desti nation) ; 
MessageListener listener = new MyMessageLi stener( ) ; 
MessageConsumer . setMess age Li stener( 1 i stener ) ; 
Thread. sleep(60) ; 
messageConsumer.cl ose( ) ; 



Versions de JMS 

JMS 1.0.2 fait la distinction entre les differents domaines de messagerie, entrainant de 
serieuses limitations dans la gestion des transactions et l'uniformisation des API de la 
technologie. 

La version 1.1 uniformise ces deux domaines, mais reste compatible avec les API de la 
version precedente. De ce fait, la plupart des entites de la version 1.0.2 sont desormais des 
sous-classes des entites de la version 1.1. 

Le tableau 12-5 recapitule les differentes entites de ces deux versions de JMS. 



Tableau 12-5. Entites des versions 1.0.2 et 1.1 de JMS 



Entite JMS 1.1 


Entite JMS 1.0.2 (file) 


Entite JMS 1.0.2 (sujet) 


Connecti onFactory 


QueueConnecti onFactory 


Topi cConnecti onFactory 


Connection 


QueueConnection 


TopicConnection 


Session 


QueueSession 


TopicSession 


MessageProducer 


QueueSender 


Topi cPubl i sher 


MessageConsumer 


QueueRecei ver 


TopicSubscriber 


Destination 




Queue 


Topic 



Support JMS de Spring 

Le support JMS de Spring, facilite Futilisation de cette technologie aussi bien pour son para- 
metrage que pour son utilisation. 

Nous detaillons dans cette section la configuration des entites JMS, ainsi que la classe centrale 
du support et la facon dont le framework gere l'envoi et la reception de messages JMS. 

Le support JMS de Spring concerne les versions 1.0.2 et 1.1, mais nous ne detaillons dans cet 
ouvrage que le support cette derniere. 
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Configuration des entries JMS 

La premiere chose a mettre en place ann d'utiliser les API de JMS est la fabrique de 
connexions. La plupart du temps, les fournisseurs JMS les rendent disponibles aux applica- 
tions clientes par le biais de JNDI. Ces entites doivent etre configurees prealablement par 
Fintermediaire d'outils d' administration. 

La balise j ndi - 1 ookup de Fespace de nommage j ee peut etre mise en ceuvre ann de les utiliser, 
comme dans Fexemple de code suivant : 

<jee: j ndi -looup id="jmsConnect ion Factory" 

jndi - name="my Connect ion Fa ctory"> 
<jee:environment> 

(...) 
</jee:envi ronment> 
</jee: jndi -lookup> 

Notons qu'il est indispensable de specifier Fenvironnement JNDI associe ail fournisseur JMS. 
Le support JMS laisse la possibility de configurer la fabrique en tant que Bean. 

La deuxieme etape consiste a determiner les differentes destinations que F application utilise 
et la maniere dont elle y accede. Le support JMS definit Fabstraction DestinationResolver 
dans le package org. spring-framework, jms. support. destination dans le but de recuperer une 
instance a partir d'un nom par Fintermediaire de la methode resolveDestinationName decrite 
ci-dessous : 

public interface DestinationResolver { 
Destination resol veDestinati onName( 



Cette interface possede deux implementations, localisees dans le meme package que 
precedemment : Jndi DestinationResolver, qui resout le nom en utilisant JNDI, et 
DynamicDestinationResolver, qui utilise les methodes createQueue et createTopic de la 
session JMS afin de creer dynamiquement des files et des sujets JMS. Elles doivent etre utili- 
sees lorsque les differentes entites du support sont configurees avec des noms de destination et 
non des instances. 




Session session, String destinationName, 
boolean pubSubDomain) throws JMSException; 



ActiveMQ 



ActiveMQ est un fournisseur JMS Open Source particulierement leger et performant. Entierement ecrit en 
Java, il peut etre utilise en mode autonome ou embarque dans une application ou des tests unitaires. Ce 
projet est devenu recemment un sous-projet du projet Geronimo d'Apache, correspondant a une imple- 
mentation complete de Java EE. II est accessible a I'adresse http://www.activemq.org/. 



II est toujours possible d'utiliser la balise jndi -lookup precedente afin de recuperer une 
instance de la destination, comme dans le code suivant pour le fournisseur JMS 
ActiveMQ : 
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<jee:jndi-looiip id="jmsQueue" jndi -name="queue"> 
<jee:envi ronment> 

j a va. naming. factory. i nit i al- 
ong, act i vemq . jndi . Act i veMQIniti al Context Factory 
java.naming.provider.url=tcp: //local host:61616 
queue. queue=tudu. queue 
</jee:envi ronment> 
</jee: jndi -lookup> 

Le template JMS 

Le template JMS est la classe centrale du support JMS de Spring puisqu'elle facilite Finteraction 
entre le fournisseur JMS et 1' application. 

II existe deux versions de cette entite, correspondant aux differentes versions de la specification 
JMS, mais nous ne detaillons que celle relative a la version 1.1. 

Ce template s'appuie sur une fabrique de connexions JMS et une destination configurees de la 
meme maniere que precedemment. Etant donne qu'il possede differentes proprietes de para- 
metrage, il est recommande de le configurer dans Spring de la facon suivante : 

<bean id="jmsTempl ate" 

cl ass="org. springf ramework. jms . core. JmsTempl ate"> 

<property name=" connect i on Factory " ref=" jmsConnect ion Factory "/> 

<property name="destination" ref=" jmsQueue"/> 

(...) 
</bean> 

Le template peut etre configure en tant que singleton, puisqu'il se fonde directement sur une 
fabrique de connexions JMS, et etre injecte ensuite dans les composants de 1' application. 

Le tableau 12-6 recapitule les differents parametres de configuration du template JMS, cette 
entite correspondant a la classe JmsTempl ate. 



Tableau 1 2-6 Proprietes de la classe JmsTemplate 



Propriete 


Utilisation 


Description 


destinationResol ver 


Envoi et reception 
(par defaut null) 


Correspond a I'entite utilisee afin de recuperer ins- 
tance de la destination dont le nom a ete configure 
par I'intermediaire de la propriete def aul tDestina- 
ti on. Elle est de type DestinationResol ver. 


sessionTransacted 


Envoi et reception 
(par defaut false) 


Permet de determiner si les sessions JMS creees 
sont transactionnelles. 


sessionAcknowl edgeMode 


Envoi (par defaut 

Ses si on. AUT0_AC KNOWLEDGE) 


Correspond au mode d'acquittement des messages 
envoyes. 


defaultDestination 


Envoi et reception 
(par defaut null) 


Correspond a la destination par defaut. Elle peut etre 
renseignee aussi bien avec I'instance de la destina- 
tion qu'avec son nom. Cette propriete est utilisee par 
les methodes du template ne possedant pas d'infor- 
mation de destination en parametre. 
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Tableau 12-6 Proprietes de la classe JmsTemplate (suite) 



Propriete 


Utilisation 


Description 


messageConverter 


Envoi et reception 
(par defaut null) 


Correspond a I'entite utilisee afin de construire un 
message a partir d'un objet et de recuperer un 
objet a partir d'un message. Elle est de type Mes- 
sageConverter et est decrite a la section sui- 
vante. 


messageldEnabl ed 


Envoi 

(par defaut true) 


Determine si la generation des identifiants des mes- 
sages JMS est activee. 


messageTimestampEnabl ed 


Envoi 

(par defaut true) 


Determine si la generation des estampilles temporel- 
les des messages JMS est activee. 


pubSubNoLocal 


Envoi et reception 
(par defaut false) 


Est necessaire pour ce template afi n d'utiliser la crea- 
tion dynamique de destinations. 


receiveTimeout 


Reception 
(par defaut -1) 


Correspond au temps d'attente de reception de mes- 
sages. Si sa valeur est superieure ou egale a 0, cette 
propriete est passee en parametre de la methode 
recei ve de la session JMS. Dans le cas contraire, la 
methode receive est bloquee jusqu'a I'arrivee d'un 
message. 


expl ici tQosEnabl ed 


Envoi 

(par defaut false) 


Permet d'activer ('utilisation des parametres del i - 
veryMode, priority et timeToLive lors de I'envoi 
de messages JMS. Si la valeur de cette propriete 
est true, les proprietes precedentes sont passees 
en parametres de la methode send de la session 
JMS. 


del iveryMode 


Envoi (par defaut 

Message. DEFAULT_DELIVERY_MODE) 


Correspond au mode de distribution des messages 
envoyes. 


priority 


Envoi (par defaut 

Message. DEFAULT_PRIORITY) 


Correspond a la priorite des messages envoyes. 


timeToLive 


Envoi (par defaut 

Message. DEFAU LT_TIME_TO_LIVE) 


Correspond a la configuration de la date d'expiration 
des messages envoyes. 



Ces parametres peuvent etre specifies sur l'instance du template grace aux fonctionnalites de 
Spring relatives a l'injection de dependances. 



Envoi de messages 

La classe JmsTemplate facilite I'envoi de messages au fournisseur JMS en integrant toute la 
manipulation des API JMS, tout en laissant la possibilite au developpeur de specifier les 
parties propres a son application. 

Afin d'envoyer des messages JMS, le template permet de travailler directement sur des 
ressources JMS qu'il gere par le biais de methodes de rappel, et ce aux niveaux a la fois de la 
session et du producteur. II s'appuie pour cela sur les interfaces SessionCallback et 
ProducerCal 1 back. 
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L'interface SessionCallback met a disposition la session grace a la methode dolnjms, comme 
ci-dessous : 

| public interface SessionCallback { 

Object doInJms(Session session) throws JMSException; 

I J 

L'interface ProducerCal 1 back enrichit cette signature de methode afin de rendre disponible le 
producteur de message, comme ci-dessous : 

public interface ProducerCal 1 back { 
Object doInJms(Session session, 

MessageProducer producer) throws JMSException; 

} 

Le template JMS utilise ces interfaces par F intermediate de methodes execute de la maniere 
suivante : 

final Destination destination = getDestination( ) ; 
JmsTempl ate template = getJmsTempl ate( ) ; 
template. execute(new ProducerCal 1 back( ) { 
public Object doInJms(Session session, 

MessageProducer producer) throws JMSException { 
TextMessage message = session .createTextMessage( ) ; 
message. setText( "Le texte du message."); 
producer. send (destination .message) ; 

} 

}); 

Creation et envoi de messages 

Le template JMS peut etre parametre avec une implementation de l'interface MessageCreator 
du package org. springframework. jms. core afin de specifier la facon de creer le message a 
envoyer. Le code suivant donne sa definition : 

public interface MessageCreator { 

Message createMessage(Session session) throws JMSException; 

} 

Ce mecanisme peut etre mis en ceuvre avec toutes les methodes send du template JMS possedant 
un parametre de type MessageCreator, comme ci-dessous : 

JmsTempl ate template = getJmsTempl ate( ) ; 
template. send(new MessageCreator( ) { 

public Message createMessage(Session session) 

throws JMSException { 
TextMessage message = session .createTextMessage( ) ; 
message. setText( "Le texte du message."); 
return message; 

} 

} 
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Conversion et envoi de messages 

Le support JMS de Spring fournit 1' interface MessageConverter dans le package 
org.springframework. jms .support. converter afin de generaliser le mecanisme precedent a la 
reception (conversion d'un message en objet) et a Fenvoi (conversion d'un objet en message) 
de messages. 

Contrairement au createur, un convertisseur de messages est global au template JMS. Son 
code est le suivant : 

public interface MessageConverter { 

Message toMessage(Object object, Session session) 

throws JMSException, MessageConversionException; 
Object f romMessage(Message message) 

throws JMSException, MessageConversionException; 

} 

L'utilisateur doit specifier dans une classe la facon de passer d'un message a un objet, et inver- 
sement. Le code suivant decrit son utilisation avec des messages de type TextMessage : 

public MonConverti sseur implements MessageConverter { 

public Message toMessage(Object object, Session session) 

throws JMSException, MessageConversionException { 
TextMessage message = session. createTextMessage( ) ; 
if( object instanceof String ) { 

message. setText( (St ring) object) ; 
} else { 

message. setText( object . toSt ring ( ) ) ; 

} 

return message; 



public Object f romMessage(Message message) 

throws JMSException, MessageConversionException { 
if( message instanceof TextMessage ) { 

return ( (TextMessage) mess age) . getText( ) ; 
} else { 

throw new MessageConversionException( 

"Type de message non supporte."); 

} 

} 

Cette implementation est rattachee au template precedent de la maniere suivante 
<bean id=" jmsMessageConverter" cl as s=" MonConverti sseur "/> 

<bean id="jmsTempl ate" 

cl ass-"org.springf ramework. jms. core. JmsTempl ate"> 

<property name="messageConverter" ref=" jmsMessageConverter "/> 

(...) 
</bean> 
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Ce mecanisme peut etre mis en ceuvre avec toutes les methodes convertAndSend du template 
JMS, comme ci-dessous : 

JmsTempl ate template = getJmsTempl ate( ) ; 
j tempi ate. convertAndSend ("Le texte du message."); 

Notons que ce code utilise le convertisseur configure precedemment sur le template JMS. 
Postprocessing des messages 

L'envoi de messages avec conversion offre la possibilite de realiser des traitements sur les 
messages immediatement avant qu'ils soient envoyes. Ce mecanisme se fonde sur 1' interface 
MessagePostProcessor suivante du package org. springframework. jms. core : 

public interface MessagePostProcessor { 

Message postProcessMessage(Message message) 

throws JMSException; 

} 

L'exemple suivant decrit une mise en ceuvre possible de cette entite afin d'ajouter automati- 
quement un identifiant de correlation a chaque message envoye : 

JmsTempl ate template = getJmsTempl ate( ) ; 
template. convertAndSendC'Le texte du message.", 
new MessagePostProcessor( ) { 
public Message postProcessMessage(Message message) 

throws JMSException { 
String correl ationld = getCorrel ationldf ) ; 
message. set JMSCorrel ati on I D( correl ationld) ; 

} 

}); 



Reception de messages 

Le support JMS de Spring permet de recevoir des messages JMS de maniere synchrone ou 
asynchrone. La mise en ceuvre de ces fonctionnalites se fonde sur des entites differentes. 

La reception synchrone implique une action de F application cliente JMS afin de recuperer les 
messages, action pouvant etre bloquante. Cette fonctionnalite utilise la classe centrale du 
support JMS, a savoir la classe JmsTempl ate. 

La reception asynchrone met en ceuvre des observateurs JMS, le support JMS fournissant un 
cadre, denomme conteneur de gestion des observateurs, afin d'enregistrer ces observateurs 
aupres des ressources JMS appropriees. 

Reception synchrone de messages 

Puisque le support JMS offre la possibilite de travailler sur une session geree par le template 
par l'intermediaire de l'interface SessionCallback, il est possible de creer une instance de 
MessageConsumer afin de recevoir des messages. 
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Notons que Spring ne deflnit pas d'interface ConsumerCallback, a la maniere de l'interface 
ProducerCal 1 back. La mise en ceuvre de l'interface SessionCal 1 back n'est pas recommandee dans 
ce cas, car le developpeur a la responsabilite de gerer Finstance de consommation des messages. 
Le template JMS fournit des methodes afin d'encapsuler toute cette logique technique. 

Comme pour F envoi de messages, la reception se decompose en deux parties, dont la 
premiere recupere directement le message recu. Elle s'appuie pour cela sur les methodes 
receive et receiveSelected. Cette derniere offre la possibilite d'utiliser un selecteur de 
message afin de cibler les messages desires. 

Le code suivant en donne un exemple d' utilisation : 

JmsTempl ate template = getJmsTempl ate( ) ; 
Message message = tempi ate. receive( ) ; 

Notons que la methode recei ve de cet exemple utilise tous les parametrages du template realises 
precedemment. 

La seconde methode permet d'utiliser le mecanisme de conversion aborde lors de l'envoi de 
message, toutes les methodes nominees recei veAndConvert et recei veSel ectedAndConvert 
mettant en ceuvre ce mecanisme. 

Ce dernier type de methode offre la possibilite d'utiliser un selecteur de message afin de cibler 
les messages desires. Le code suivant en donne un exemple d'utilisation : 

JmsTempl ate template = getJmsTempl ate( ) ; 

String txtMessage = (String)templ ate. recei veAndConvert( ) ; 

Notons que la methode receive de cet exemple utilise egalement tous les parametrages realises 
precedemment sur le template ainsi que sur le convertisseur MonConverti sseur. 

Reception asynchrone de messages 

Le support JMS integre un cadre robuste afin de mettre en ceuvre les mecanismes de reception 
asynchrones de JMS. Spring implemente pour cela deux approches. La premiere utilise 
l'entite MessageConsumer et sa methode setListener, et la seconde l'entite ServerSession. 

Ces deux approches ont en commun les proprietes recapitulees au tableau 12-7. 



Tableau 12-7. Proprietes communes des conteneurs JMS de Spring 



Propriete 


Description 


destinationResol ver 


Correspond a l'entite utilisee afin de recuperer I'instance de la destination dont 
le nom a ete configure par I'intermediaire de la propriete defaultDestina- 
ti on. Elle est de type DestinationResol ver. 


connectionFactory 


Correspond a la fabrique de connexions a utiliser. 


sessionTransacted 


Permet de determiner si les sessions JMS creees sont transactionnelles. 


sessionAcknowl edgeMode 


Correspond au mode d'acquittement des messages envoyes. 


messageSel ector 


Correspond a l'entite utilisee afin de filtrer les messages a recevoir. 


messageLi stener 


Correspond a I'instance de I'observateur JMS utilise. 
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Tableau 12-7. Proprietes communes des conteneurs JMS de Spring (suite) 



Propriete 


Description 


expose Li stenerSession 


Permet de specifier si la session a fournir aux observateurs JMS de type Ses - 
sionAwareMessageLi stener est celle utilisee pour la reception des messa- 
ges. 


autoStartup 


Specifie si la methode start de la connexion JMS doit etre appelee au char- 
gement du conteneur. Si sa valeur est false, il est possible de le demarrer 
ulterieurement avec la methode start du conteneur. L'arret de la reception 
des messages est realise avec la methode stop. 


destination 


Correspond a la destination a utiliser. Elle peut etre renseignee avec I'instance 
de la destination ou son nom. 



Le premier conteneur JMS de Spring est implemente par V intermediate de la classe 
SimpleMessageListenerContainer du package org.springframework. jms.l istener. Cette 
classe corTespond a la forme la plus simple et n'offre pas une approche multithread. 

II est possible de parameter le nombre de sessions utilisees pour la reception des messages 
par F intermediate de la propriete concurrentConsumers. Ce conteneur ne permet pas de modifier 
dynamiquement sa configuration au cours de 1' execution. 

Le code suivant donne un exemple de sa mise en ceuvre : 

<bean id="connectionFactory" 

cl as s=" org. act ivemq. Act iveMQConnecti on Factory "> 
<property name="brokerllRL" value="tcp://localhost:61616"/> 
</bean> 

<bean id="asynchTuduJmsLi stener" 

cl ass="tudu. jms . AsynchTuduJmsLi stener "/> 

<bean id="jmsContainer" class="org.springframework. jms 

. 1 istener . Def a ul tMessageLi stenerContainer"> 
<property name=" connect i on Factory" ref=" connect ion Factory "/> 
<property name="destinationName" val ue="tudu.queue"/> 
<property name="mes sage Li stener" ref="asynchTuduJmsLi stener" /> 

</bean> 

Le second conteneur, implemente par F intermediate de la classe ServerSession- 
MessageListenerContainer du meme package, est beaucoup plus evolue. II se fonde sur les 
API JMS ServerSessionPool, generalement mises en ceuvre par - les serveurs d' applications. 
II permet de realiser la reception de messages de maniere multithreadee et se configure de la 
meme maniere que le precedent. 

Message Driven Pojos 

Le support JMS donne la possibilite de configurer un Bean simple en tant qu'observateur JMS 
en se fondant sur la classe MessageListenerAdapter, localisee dans le package 
org.springframework. jms. listener. adapter. Cette derniere se positionne en tant que proxy 
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devant le Bean et permet de positionner la methode a appeler lors de la reception d'un 
message. 

Le code suivant illustre la configuration du Bean cible par Fintermediaire de la propriete 
del egate (Q) et de la methode appelee avec la propriete defaul tListenerMethod (Q) : 

<bean id="monBean" cl ass="( . . . )"/> 

<bean id="l i stener" cl ass-" org. springf ramework. jms . 1 i stener 

. adapter. MessageLi stenerAdapter"> 
<property name="del egate" ref="monBean"/><— © 
<property name=" defaul tl_istenerMethod"<— Q 
val ue="processRequest"/> 

</bean> 

Espace de nommage 

Dans le contexte des receptions asynchrones, Spring met a disposition l'espace de nommage 
jms. Ce dernier permet de configurer simplement les conteneurs JMS de Spring et de meftre en 
ceuvre facilement des Message Driven Pojos, et ce avec une grande facilite de configuration, 
les concepts decrits precedemment etant identiques. 

Cet espace de nommage se configure de maniere classique (Q) a Faide des facilites de XML 
au niveau de la balise beans, comme le montre le code suivant : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. spri ngframework.org/schema/beans" 

xml ns :xsi="http: //www.w3. org/2001 /XMLSchema-i nstance" 

xml ns : jms="http: //www. springf r amework.org/schema /jms" <— © 

xsi : schemaLocati on=" 

http: //www. spri ngframework.org/schema/beans 
http: //www. springf ramework.org/schema/ 

beans / spring -beans -2. 5. xsd 
http: //www. spri ngf ramewo rk.org/schema /jms <— © 
http: //www. springf ramework.org/schema/ 

jms /spring- jms -2. 5. xsd "> 

La balise 1 istener-container permet de configurer le conteneur JMS, les differents observa- 
teurs etant specifies par la suite en se fondant sur des balises imbriquees. Le tableau 12-8 reca- 
pitule les differentes proprietes utilisables par la balise listener-container : 



Tableau 12-8. Proprietes de la balise listener-container de l'espace de nommage jms 



Propriete 


Description 


container-type 


Specifie le type du conteneur a utiliser. Les valeurs possibles sont default, simple, 
defaul 1 102 et simpl el02, sachant que la valeur par defaut est default. 


connection-factory 


Specifie I'identifiant du Bean correspondant a la fabrique de connexion JMS a utiliser. 
La valeur par defaut est connectionFactory. 


task-executor 


Specifie I'identifiant d'un Bean de type TaskExecutor de Spring afin d'invoquer les 
observateurs JMS. 



Support des technologies JMS et JCA 

Chapitre 12 



Tableau 12-8. Proprietes de la balise listener-container de I'espace de nommage jms (suite) 



Propriete 




Description 


destination 


resolver 


Reference un Bean de type DestinationResol ver afin de specifier une strategie de 
resolution des destinations. 


message-converter 


Reference un Bean de type MessageConverter afin de specifier une strategie pour 
convertir les messages JMS en parametres des methodes des observateurs. Par 
defaut, il s'agit d'une entite de type Simpl eMessageConverter. 


destination 


-type 


Specifie le type de destination. Les valeurs possibles sont queue, topic et durable - 
Topi c, sachant que la valeur par defaut est queue. 


cl ient-id 




Specifie I'identifiant du client pour le conteneur. Cela se revele necessaire lors de ['uti- 
lisation des souscriptions durables. 


cache 




Configure le niveau de cache des ressources JMS. Les valeurs possibles sont none, 
connection, session, consumer et auto (valeur par defaut). 


acknowl edge 




Specifie letype d'acquittement JMS pour les observateurs. Les valeurs auto, cl ient, 
dups-ok et transacted sont possibles, sachant que la valeur par defaut est auto et 
que transacted active les transactions locales. Une autre possibilite consiste a utiliser 
des transactions gerees par Spring. 


transaction 


manager 


Reference un Bean correspondant a une implementation de I'interface Platform- 
TransactionManager afin de gerer les transactions. 


concurrency 




Specifie le nombre de sessions/consommateurs JMS concourants a demarrer pour 
chaque observateur. 


prefetch 




Specifie le nombre maximal de messages a charger pour une session JMS. 



Le conteneur peut contenir une ou plusieurs configurations d' observateurs JMS par F interme- 
diate de la balise 1 i stener. Cette balise integre directement la possibilite de mettre en ceuvre 
des Message Driven Pojos en permettant le referencement de Beans classiques en tant 
qu'observateurs JMS. II integre en effet directement la configuration de la classe Message- 
Li stenerAdapter precedemment decrite. 

Le tableau 12-9 recapitule les differentes proprietes de la balise listener de I'espace de 
nommage jms. 



Tableau 12-9. Proprietes de la balise listener de I'espace de nommage jms 



Propriete 


Description 


id 


Identifiant du Bean correspondant au conteneur configure. 


destination 


Specifie la destination JMS sur lequel I'observateur est applique. 


ref 


Reference le Bean utilise en tant qu'observateur JMS. Aucune dependance sur les API 
JMS n'est necessaire et I'interface MessageLi stener n'a pas a etre implementee. 


method 


Correspond a la methode du Bean a utiliser lors de la reception d'un message JMS . 


response -destination 


Specifie le nom de la destination par defaut pour renvoyer des messages. Cet aspect 
ne s'applique qu'aux methodes des observateurs ayant un retour. 


subscription 


Configure le nom de la souscription durable si cette fonctionnalite doit etre mise en oeuvre. 


sel ector 


Specifie un selecteur optionnel pour I'observateur. 
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Le code suivant illustre la mise en oeuvre de Fespace de nommage pour configurer un Bean simple 
en tant qu'observateur JMS (©) par l'intermediaire d'un conteneur JMS (©) de Spring : 

(...) 

<bean id="monBean" class - " (...)"/> 

<jms : 1 i stener -container*— Q 

connect i on -factory-" connect ion Factory" 
concurrency-"10"> 
<jms : 1 i stener desti na tion="tudu. queue" <—Q 

ref="monBean" method="processRequest"/> 
</jms :1 i stener -container 

En resume 

Le support JMS de Spring reduit la complexite liee a F utilisation de cette technologie. II 
permet de configurer facilement les differentes entites de JMS dans le conteneur leger et de 
s'appuyer sur une entite principale gerant les interactions avec le fournisseur JMS. II adresse 
aussi bien remission que la reception de messages JMS. 

Le support offre egalement une facon elegante et simple de mettre en oeuvre des observateurs 
JMS afin d'utiliser les mecanismes asynchrones de communication de la technologie. La 
configuration de simples Beans en tant qu'observateur est possible, et un espace de nommage 
dedie est mis a disposition afin de faciliter cette configuration. 

La specification JCA (Java Connector Architecture) 

Cette section se penche sur les preoccupations generates des interactions avec les systemes 
d'information d'entreprise ainsi que sur les concepts de la specification JCA visant a les 
resoudre avec Java. 

La specification JCA definit les mecanismes permettant d'acceder de maniere uniformisee a 
des systemes d'information d'entreprise heterogenes. Ces derniers peuvent utiliser diverses 
technologies, dont Java/Java EE, et correspondre, par exemple, a des moniteurs transactionnels 
pour mainframes (CICS, IMS) ou a des ERP (SAP, PeopleSoft, etc.). 
La specification JCA comprend deux versions : 

• Version 1.0. Adresse la facon d'interagir avec des systemes d'information d'entreprise par 
l'intermediaire de requetes tout en recourant aux services Java EE. Elle standardise une API 
cliente, appelee Common Client Interface, afin d'interagir avec ses systemes d'une maniere 
similaire a JDBC mais plus generique. 

• Version 1.5. Enrichit la version precedente avec le support des connexions entrantes sur les 
connecteurs. Les systemes d'information peuvent envoyer des messages au connecteur, 
lequel notifie les observateurs enregistres. Cet ajout est fortement lie a la specification JMS 
permettant de normaliser ses interactions avec les services Java EE. 

Lobjectif de la specification est de standardiser les interactions entre les connecteurs et un 
fournisseur de services. Nous faisons ici la distinction entre fournisseur de services et serveur 
d' applications, puisque les deux ne sont pas forcement equivalents. Un serveur d' applications 
correspond a un fournisseur de services, mais la reciproque n'est pas verifiee. 
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Les mecanismes de JCA peuvent etre utilises afin de faire interagir des ressources Java/Java 
EE avec des services tels qu'un gestionnaire de transactions compatible JTA. 

La specification n' impose pas FAPI cliente a utiliser, celle-ci etant determinee par 1' imple- 
mentation du connecteur. Ce dernier peut necessiter l'utilisation de Common Client Interface, 
comme c'est le cas pour des connecteurs tels que ceux d'IBM, permettant d'acceder a de gros 
systemes, tels que CICS ou IMS, mais egalement permettre la configuration de fabriques de 
connexions ou de sessions, telles que celles de JDBC, JMS ou Hibernate. 

La technologie JCA est de plus en plus utilisee dans les serveurs d' applications afin de confi- 
gurer les differentes ressources qu'ils utilisent et de les faire interagir avec leurs services. 
Geronimo, par exemple, le serveur Java EE de la fondation Apache, configure les pools de 
connexions JDBC a partir de JCA et de son connecteur generique, TranQL. 

La specification JCA comporte deux parties distinctes : 

• Partie cliente. Utilisable dans les applications Java/Java EE afin d'interagir avec les 
systemes d'information d'entreprise. 

• Partie fournisseur de services. Utilisable par les serveurs d' applications ou les frameworks 
afin de configurer Fenvironnement d'execution de JCA aussi bien pour les communications 
sortantes qu'entrantes. 



Gestion des communications sortantes 

JCA offre un cadre afin de configurer la fabrique de connexions ou de sessions de differents 
frameworks ou technologies. Le connecteur a la responsabilite de travailler sur les connexions 
ou sessions physiques et fournit a 1' application cliente des connexions logiques. 

Ce mecanisme permet de realiser des interceptions de traitements afin d'inserer des fonction- 
nalites transversales de maniere transparente, telles que les transactions et la securite. 

La figure 12-4 illustre les interactions entre le connecteur et F application, ainsi que celles 
avec le fournisseur de services. 



Application 



Fabrique (connexions ou 
sessions) 



T 



Connexion ou session £ 



Connecteur 



ManagedConnectionFactory 



ManagedConnection 



Fournisseur de services 



Gestionnaire de 
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connexions (pool) 
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Figure 12-4 

Interactions du connecteur avec V application et le fournisseur de sendees 
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Sur cette figure, les differentes entites manipulees par 1' application peuvent etre celles de 
FAPI Common Client Interface de JCA ou celles d'autres technologies ou frameworks, tels 
JDBC, JMS ou Hibernate. De meme, le fournisseur de services peut etre aussi bien un serveur 
d' applications que des composants autonomes. 

Le connecteur peut fonctionner en mode autonome, sans utiliser de fournisseur de services. II 
utilise alors son gestionnaire de connexions interne, mais ne peut plus utiliser les transactions 
globales. 

L' implementation de l'interface ManagedConnectionFactory doit dans ce cas etre instanciee 
explicitement par 1' application afin d' avoir acces a la fabrique, comme dans le code suivant : 

ManagedConnectionFactory managedConnect ion Factory 

= createAndConfigureManagedConnectionFactory( ) ; 
Object connectionFactory 

= ma nagedConnect ion Factory . createConnecti on Factory ( ) ; 

Notons l'existence de la methode createConnecti onFactory, possedant un parametre de type 
ConnectionManager qui permet de specifier un gestionnaire de connexions pour le connecteur 
et d' utiliser le connecteur avec un fournisseur de services specifie explicitement. Dans ce cas, 
Futilisation des transactions globales est envisageable. 

JCA est sou vent utilise pour configurer des fabriques de connexions ou de sessions afin de les 
faire participer a des transactions globales, la specification normalisant cette interaction quelle 
que soit la technologie employee. 

L'API Common Client Interface permet aux applications Java/J2EE d'interagir avec des 
systemes d' information d'entreprise selon les etapes suivantes : 

1. Creation de la fabrique de connexions. 

2. Recuperation d'une connexion a partir de la fabrique precedente. Elle est parametree 
par l'intermediaire d'une implementation de la classe ConnectionSpec relative au 
connecteur. 

3. Creation d'une interaction a partir de la connexion precedente. 

4. Execution de la requete, qui peut etre parametree par le biais d'une implementation 
de la classe InteractionSpec relative au connecteur. Les parametres ainsi que les 
retours sont decrits par des implementations de la classe Record et de ses derivees. 

Notons que les interfaces ConnectionSpec et InteractionSpec sont des classes marqueurs ne 
definissant aucune methode. 

La fabrique de connexions JCA est normalised par l'intermediaire de l'interface 
ConnectionFactory du package javax.ressource. Son unique fonction est de creerdes connexions 
pour un systeme d'information d'entreprise, comme le montre le code suivant de l'interface : 

public interface ConnectionFactory { 
Connection getConnection( ) ; 

Connection getConnection(ConnectionSpec properties); 
ResourceAdapterMetaData getMetaData( ) ; 
RecordFactory getRecordFactory( ) ; 

} 
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La connexion correspond a l'entite de communication avec le systeme. Sa creation peut etre 
parametree par F intermediate d'une implementation de ConnectionSpec du connecteur, 
lequel permet, de maniere classique, de specifier des parametres d'authentification afin 
d'etablir la connexion. 

Le code suivant donne la definition de cette entite : 

public interface Connection { 
void closeO; 

Interaction createlnteractiont ) ; 
LocalTransaction getl_ocalTransaction( ) ; 
ConnectionMetaData getMetaData( ) ; 
Resul tSetlnfo get Res ul tSetInfo( ) ; 

} 

Cette entite offre un support afin de demarquer les transactions locales en rendant accessible 
une implementation de l'interface LocalTransaction pour le connecteur. 

Linteraction permet d'executer une requete vers le systeme. Elle offre deux approches a cet 
effet, dont une seule est supportee par les connecteurs. La premiere consiste a passer les para- 
metres d'entree sous forme de Record et de recuperer les resultats sous la meme forme. La 
seconde attend en parametres un premier Record contenant les parametres d'entree et un autre 
Record rempli suite a F execution avec les parametres de retour. 

Le code suivant donne la definition de cette entite : 

public interface Interaction { 
void cl earWarnings( ) ; 
void close( ) ; 

Record execute( Interacti onSpec ispec, Record input); 
boolean executednteractionSpec ispec, 

Record input, Record output); 
Connection getConnection( ) ; 
ResourceWarning getWarni ngs( ) ; 

} 

La mise en ceuvre de ces differentes entites afin d'interagir avec un systeme d'information 
d'entreprise avec la premiere approche se deroule de la facon suivante : 

Connection connection = null; 
Interaction interaction = null; 

try { 

Connecti onFactory connectionFactory = getConnectionFactory( ) ; 

ConnectionSpec ConnectionSpec = createConnectionSpec( ) ; 
connection = connectionFactory .getConnection(connectionSpec) ; 

interaction interaction = connecti on. createInteraction( ) ; 
InteractionSpec interactionSpec = createInteractionSpec( ) ; 
Record inputRecord = createInputRecord( ) ; 
Record outputRecord = interaction. execute( 

interactionSpec. inputRecord); 
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(...) 

} catch(Exception ex) { 

convertResourceException(ex) ; 
} finally { 

cl ose Interact!' on (interaction) ; 

cl oseConnecti on (connection) ; 



Gestion des communications entrantes 

Comme indique precedemment, la version 1.5 de JCA enrichit la specification avec le support 
des communications entrantes. Le systeme d'information d'entreprise peut ainsi rappeler le 
connecteur afin de lui envoyer des messages. Ce mecanisme est souvent utilise conjointement 
avec la specification JMS et trouve toute son utilite avec les outils de messagerie asynchrone 
tels que les fournisseurs JMS. 

La figure 12-5 illustre les differentes interactions entre le connecteur et F application, ainsi 
que celles avec le fournisseur de services. 
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Figure 12-5 

Interactions du connecteur avec I 'application et le fournisseur de services 



La specification definit 1' interface ResourceAdapter decrivant le connecteur et permettant 
d'enregistrer des points d'acces, materialises par des implementations de 1' interface 
Acti vati onSpec. Le connecteur doit avoir ete prealablement demarre et initialise avec des entites 
du fournisseur de services et arrete a la fin de son utilisation. 
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Le code suivant foumit les differentes methodes de l'interface ResourceAdapter : 

public interface ResourceAdapter { 
(...) 

//Enregistrement et desenregi strement de points d'entree 
void endpoi n t Act ivati on (MessageEndpoint Factory endpoi nt Factory , 

ActivationSpec spec); 

void endpoi ntDeactivati on ( 

MessageEndpoint Factory endpoi nt Factory, 

ActivationSpec spec); 
//Demarrage et arret du connecteur 
void start(BootstrapContext ctx); 
void stopO; 

} 

Lors de l'activation d'un point d'acces, 1' implementation de l'interface ResourceAdapter 
utilise la fabrique MessageEndpointFactory arm d'instancier une unite de traitement de type 
MessageEndpoint. Cette entite met en ceuvre les mecanismes transactionnels en se fondant sur 
le cycle de vie du traitement: avant la reception d'un message (beforeDel ivery), apres sa 
reception (afterDel ivery) et au moment de la finalisation du traitement (release). 

Nous constatons que cette partie de JCA offre des similitudes avec la reception asynchrone de 
messages de la specification JMS, tout en foumissant un cadre plus generique. Dans le cas des 
fournisseurs JMS, les MessageEndpoint peuvent etre relies a des observateurs JMS, lesquels 
seront notifies lors de la reception de messages. 

Support JCA de Spring 

L'objectif du support JCA de Spring est de faciliter l'utilisation de l'API Common Client 
Interface, ainsi que la configuration des connecteurs en mode non manage — c'est-a-dire en 
dehors des serveurs d' applications — et celle des communications entrantes asynchrones. 

Dans le cas des communications sortantes, le support JCA reprend les concepts du support 
JDBC de Spring en l'adaptant a l'API Common Client Interface. II inclut dans le framework 
la manipulation de ses entites tout en s'integrant avec le support transactionnel du framework. 

II est a noter que le support JCA met a disposition depuis la version 2.5 un support des 
communications entrantes. 

Communications sortantes 

Le framework Spring integre un support complet de la partie relative aux connexions sortantes 
permettant d'envoyer des requetes vers des systemes d'information d'entreprise en utilisant 
l'API Common Client Interface. 

Pour decrire ce support, nous utilisons le connecteur BlackBox, disponible dans le SDK de 
Java EE. Nous avons retravaille le code de ce connecteur afin de le rendre davantage parame- 
trable au niveau de la specification du pilote JDBC et de la requete SQL utilises. Le nouveau 
fichier jar est disponible dans l'etude de cas Tudu Lists. 
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Comme indique precedemment, un connecteur peut etre configure de deux manieres. 

La premiere consiste a le deployer dans un serveur d' applications afin de rendre disponible 
par le biais de JNDI une instance de la fabrique de connexions correspondante. Dans ce cas, 
aucune configuration particuliere n'est necessaire pour le connecteur. L' application doit se 
fonder sur une instance de la fabrique en utilisant la balise jndi -lookup de Fespace de 
nommage jee de Spring, comme dans le code suivant : 

<jee: jndi -looup id=" connect ion Factory" 

jndi -name="eis/monConnecteur"> 
<jee:environment> 

(...) 
</jee:envi ronment> 
</jee: jndi -lookup> 

L' autre possibilite est de configurer un connecteur en dehors d'un serveur d' applications dans 
une application. Pour ce faire, il convient d'instancier explicitement 1' implementation de 
Finterface ManagedConnecti on Factory du connecteur puis d'utiliser le support de la classe 
Local Connecti onFactoryBean du package org. springframework. jca. support afin de configurer 
une instance de la fabrique de connexions : 

<!-- Fabrique de connexion interne au connecteur --> 

<bean id="managedConnectionFactory" cl ass="com. sun . connector 

. ccibl ackbox.Cci Local TxManagedConnect ion Factory "> 
<property name=" connect ionlIRL" 

val ue="jdbc:mysql : //local host:3306/tudu"/> 
<property name="dri verName" val ue="com.mysql . jdbc.Driver"/> 
</bean> 

<!-- Fabrique de connexion associee --> 

<bean id=" connect ion Factory" class="org.springf ramework. jca 

.support . Local Connect ion Factory Bean "> 
<property name="managedConnecti on Factory" 
ref="managedConnectionFactory"/> 

</bean> 

II est possible d'utiliser le connecteur en mode manage hors d'un serveur d' applications en 
injectant une instance d'un gestionnaire de connexions JCA par 1' intermediate de la propriete 
connecti onManager. Le projet Jencks offre un support afin de configurer facilement dans 
Spring le gestionnaire de connexions JCA ainsi que le gestionnaire de transactions de Gero- 
nimo de maniere autonome. 

Avec ces deux approches, nous pouvons configurer avec JCA des fabriques de connexions de 
connecteurs. II est important de bien comprendre que ces fabriques ne sont pas necessairement 
compatibles avec l'API cliente CCI. 

II est possible de configurer une DataSource JDBC ou une SessionFactory d'Hibernate de 
cette maniere, a condition de posseder le connecteur correspondant. Puisque JCA normalise 
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les interactions avec les gestionnaires de transactions JTA, cette approche permet de rendre 
des fabriques de connexions facilement compatibles XA arm de les faire participer a des 
transactions globales (voir le chapitre 11, relatif a la gestion des transactions). 

Support de I'API Common Client Interface 

Spring offre un support de I'API cliente normalised Common Client Interface. II reprend les 
concepts du support JDBC du framework arm de simplifier F utilisation de cette API, d'encap- 
suler le code repetitif, de masquer sa complexite et de configurer la participation aux transac- 
tions. 

CCI donne la possibilite de parameter la connexion grace a 1' implementation de Finterface 
Connecti onSpec du connecteur. Le support CCI de Spring permet de mettre en ceuvre cette 
fonctionnalite par Fintermediaire de la classe ConnectionSpecConnectionFactoryAdapter du 
package org.springf ramework. jca.cci .connection, correspondant a un proxy sur la fabrique 
de connexions cible. 

Le code suivant donne la configuration de ce mecanisme : 
(...) 

<bean id="targetConnectionFactory" cl ass="org.springf ramework. jca 

.support . Local Connect ion Factory Bean" > 

(...) 

</bean> 

<bean id="myConnectionFactory" cl ass="org.springframework. jca .cci 
.connect ion. Connect ionSpecConnecti on FactoryAdapter"> 
<property name="targetConnect ion Factory" 

ref="targetConnectionFactory"/> 
<property name="connecti onSpec"> 
<bean 

cl ass=" com. sun. connector. cci bl ackbox. Cci Connect ionSpec"> 
<property name="username" val ue="root"/> 
<property name="password" value=""/> 
</bean> 
</property> 
</bean> 

Le support CCI de Spring propose deux approches d' execution de ces requetes, Tune fondee 
sur le template, 1' autre etant une approche objet. 

La classe centrale de Fapproche fondee sur le template est CciTemplate, localisee dans le 
package org.springf ramework. jca.cci .core. Elle permet de travailler directement sur les 
ressources CCI qu'elle gere par le biais de methodes de rappel, aux niveaux de la connexion 
et de l'interaction. 

Elle s'appuie pour cela sur les interfaces ConnectionCallback et InteractionCallback. La 
premiere met a disposition la connexion grace a la methode doInConnecti on, comme ci-dessous : 

public interface ConnectionCallback { 

Object do!nConnection(Connection connection, 
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Connect ion Factory connect i on Factory ) 
throws ResourceException, 

SQLExcepti on , Data Access Except i on ; 

} 

La seconde propose 1' interaction grace a la methode dolnlnteraction : 

public interface InteractionCallback { 

Object dolnlnteractiondnteraction interaction, 

Connection Factory connect i on Factory ) 
throws ResourceException, 

SQLExcepti on , Data Access Except i on; 

} 

Le template CCI utilise ces interfaces par Fintermediaire des methodes execute de la maniere 
suivante : 

CciTemplate template = getCciTempl ate( ) ; 
tempi ate. execute(new InteractionCal 1 back( ) { 

public Object dolnlnteractiondnteraction interaction, 

Connection Factory connect i on Factory ) 
throws ResourceException, 

SQLException, DataAccessExcepti on { 

IndexedRecord input = 

record Factory. create Indexed Record ( "input" ) ; 
input. add(new Integer(id) ) ; 
Cci InteractionSpec interactionSpec = 

new Cci InteractionSpec( ) ; 

interactionSpec. setSql ( 

"select * from todo where id=?"); 
Record output = interaction. execute( 

interactionSpec, input); 
return extractDataFromRecord(output) ; 

} 

}); 

Le template CCI offre des fonctionnalites permettant de masquer tout le code d' invocation 
d'une requete par Fintermediaire de ses autres methodes execute. Ces dernieres s'appuient sur 
Finterface RecordCreator afin de definir la facon de creer une instance de la classe Record a 
partir d'un objet. Le code de cette interface est le suivant : 

public interface RecordCreator { 

Record createRecord( RecordFactory recordFactory) 

throws ResourceException, DataAccessException; 

} 

Ces methodes utilisent egalement 1' interface RecordExtractor afin de recuperer dans un objet 
Java simple les donnees contenues dans un Record. Le code de cette interface est le suivant : 

public interface RecordExtractor { 

Object extractData(Record record) throws ResourceException, 

SQLExcepti on , DataAccessExcepti on ; 

} 
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Ces deux interfaces sont localisees dans le package org.springf ramework. jca.cci .core et 
peuvent etre mises en ceuvre de la maniere suivante afin de creer un Record en entree (Q) et 
d'extraire les donnees en sortie (Q) : 

final i nt id = 10; 

Cci Interacti onSpec interactionSpec=new Cci InteractionSpect ) ; 
interactionSpec.setSql ("select * from todo where id=?"); 

List peopl e=( List )getCci Tempi ate( ) . execute ( 

interactionSpec. new RecordCreator( ) {<— O 
public Record createRecord( RecordFactory recordFactory ) 

throws ResourceException, DataAccessException { 
IndexedRecord input = 

recordFactory . create Indexed Record ( "input" ) ; 
input. add(new Integer(id) ) ; 
return input; 

1 

}, new RecordExtractor( ) {<— Q 

public Object extractData(Record record) 

throws ResourceException, SQLException, DataAccessException { 
List todos = new ArrayListO; 
ResultSet rs=(ResultSet)record; 
while( rs.nextO ) { 

Todo todo=new TodoO; 

todo. setTodoId( rs .getString( "id" ) ) ; 

todo.setDescription(rs.getString( "description") ) ; 

(...) 

todos . add(todo) ; 

} 

return todo; 

1 

}); 

Puisque CCI definit une methode execute attendant le Record de retour, le template imple- 
mente un mecanisme de creation automatique de celui-ci. II s'appuie pour cela sur sa 
propriete outputRecordCreator de type RecordCreator, permettant de specifier la facon de le 
creer. Ce mecanisme est particulierement interessant pour les connecteurs ne supportant que 
cette facon de realiser des requetes. 

En parallele du template, le support CCI offre la possibility de definir les requetes CCI sous 
forme d'objets afin de beneficier de toutes les possibilites du langage objet. Cette approche se 
fonde sur la classe abstraite MappingRecordOperation du package 
org.springf ramework. jca.cci .object. Elle doit etre etendue afin d'implementer les methodes 
createlnputRecord et extractOutputData decrivant respectivement la facon de creer un Record 
et d'extraire les donnees du Record renvoye. 

La classe suivante decrit F adaptation de l'exemple de la section precedente a 1' approche objet, 
a savoir une classe mettant en ceuvre une operation en heritant de la classe 
MappingRecordOperation (Q), specifiant les donnees en entree avec la methode 
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createlnputRecord (Q) et recuperant les donnees par 1' intermediate de la methode 
extractOutputData (Q) : 

public class TodosOperation extends MappingRecordOperation {<— © 
public TodosOperation(ConnectionFactory connectionFactory, 
Interacti onSpec interactionSpec) { 
super (connect ion Factory .interact ionSpec) ; 

} 



protected Record createInputRecord(<— Q 

RecordFactory recordFactory , Object inputObject) 

throws ResourceException, DataAccessExcepti on { 
Integer id = (Integer)inputObject; 
IndexedRecord input = 



protected Object extractOutputData(<— Q 

Record outputRecord) throws ResourceException, 

SQLException, DataAccessExcepti on { 

List todos =new ArrayListO; 

ResultSet rs = (ResultSet)outputRecord; 

while (rs.nextO) { 

Todo todo=new TodoO; 

todo.setTodoId( rs .getString( "id" ) ) ; 

todo. set Descripti on( rs .getStri ng( "descri ption" ) ) ; 

(...) 

todos . add(todo) ; 

} 

return todos; 



Cette classe peut etre utilisee de la maniere suivante dans un composant d'acces aux donnees : 

I Cci InteractionSpec interactionSpec = new Cci InteractionSpec( ) ; 
interactionSpec. setSql ("select * from todo where id=?"); 

TodosOperation operation = new TodosOperation( 

getConnectionFactory( ) , interactionSpec) ; 
operation. execute (new Integer (10) ) ; 

Notons la presence de la classe MappingCommAreaOperation dans le support, qui etend la classe 
MappingRecordOperation afln de travailler directement sur des tableaux d' octets. Cette classe 
facilite l'utilisation des connecteurs tels que celui utilise dans le cas de CICS ECI et qui 
echange des donnees en se fondant sur une COMMAREA (correspondant a un tableau 
d'octets). 




recordFactory . create Indexed Record ( "input" ) ; 



input.add(id) ; 
return input; 



) 
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Communications entrantes 

A partir de la version 2.5 de Spring, un support des connexions entrantes est disponible. II 
permet notamment de configurer simplement des observateurs JMS en se fondant sur le 
connecteur JCA mis a disposition par un fournisseur JMS. 

Le framework Spring offre par ailleurs un cadre generique de JCA independant de la techno- 
logie JMS. 

Configuration du conteneur 

II convient d'abord de configurer le connecteur ainsi que Fentite de gestion du connecteur 
pour les connexions entrantes. Cette derniere est mise en ceuvre par l'intermediaire de la 
classe JmsMessageEndpointManager de Spring localisee dans le package org. spring- 
framework, jms.l istener.endpoint. 

Le connecteur doit etre configure en tant que Bean par l'intermediaire de son implementation 
de Finterface ResourceAdapter et en se fondant sur la classe ResourceAdapterFactoryBean de 
Spring localisee dans le package org. springframework. jca. support. Cette classe offre la 
possibilite de generer le cycle de vie du connecteur et de lui associer un gestionnaire de tache 
de type WorkManager. 

Le code suivant montre comment configurer le connecteur (Q) ainsi que le conteneur corres- 
pondant (Qi) du fournisseur JMS ActiveMQ : 

<bean id="resourceAdapter" cl a ss=" org. springframework. jca <— © 
.support. ResourceAdapter Factory Bean "> 
<property name="resourceAdapter"> 
<bean cl a ss=" org. apache. act ivemq 

. ra . Acti veMQResourceAdapter"> 
<property name="serverUrl " 

val ue="tcp: //l ocal host : 61 616" /> 

</bean> 
</property> 

<property name="workManager"> 

<bean cl ass="org.springf ramework 

. jca .work.Simpl eTaskWorkManager"/> 

</property> 
</bean> 



<bean cl as s=" org. springframework. jms . 1 istener<— Q 

. endpoint . JmsMessageEndpointManager"> 

<property name="resourceAdapter" ref="resourceAdapter"/> 

<property name="activationSpec"> (...) </property> 

(...) 
</bean> 

Dans ce code, les ressources necessaires sont configurees en tant que Beans imbriques. Dans 
le contexte d' ActiveMQ, F implementation de Finterface ResourceAdapter correspond a la 
classe Acti veMQResourceAdapter, classe localisee dans le package org. apache. acti vemq. ra. 
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Definition de points d'activation 

Une fois le connecteur et le conteneur mis en ceuvre, le point d'acces relatif a ce dernier doit 
etre specifie afin que le systeme d' information d'entreprise puisse les utiliser et remonter des 
informations. 

L' implementation de l'interface ActivationSpec relative au connecteur JCA doit alors etre 
utilisee. Puisque nous avons choisi d'utiliser le fournisseur JMS ActiveMQ, 1' implementation 
correspond a la classe Acti veMQActi vati onSpec. Cette classe permet de specifier le domaine du 
point d'entree ainsi que son nom. Cette entite doit etre injectee dans le conteneur par l'inter- 
mediaire de sa propriete acti vati onSpec. 

Pour que les messages puissent etre recus, un observateur doit etre specifie au niveau du 
conteneur en se fondant sur la propriete messageLi stener. Dans le cas d' ActiveMQ, cet obser- 
vateur correspond a un observateur JMS classique. 

Dans l'exemple ci-dessous, nous creons un point d'acces sur le connecteur de type 
javax.jms .Queue, dont le nom est tudu. queue (Q), et nous specifions Fobservateur JMS 
utilise (Q) : 

<bean cl ass="org.springf ramework. jms . 1 i stener 

.endpoint . JmsMessageEndpointManager"> 
<property name="resourceAdapter" ref="resourceAdapter"/> 
<property name=" acti vati onSpec "> 

<bean class="org. apache. activemq <— O 

. ra .Acti veMQActi vati onSpec "> 
<property name="destination" val ue="tudu.queue"/> 
<property name="destinationType" 

val ue=" javax.jms .Queue" /> 

</bean> 
</property> 

<property name="ref" value="asynchTuduJmsListener"/><— Q 
</bean> 

<bean id="asynchTuduJmsLi stener "<— Q 

cl ass="tudu. jms . AsynchTuduJmsLi stener "/> 

Cette configuration utilise un observateur JMS classique afin de recevoir les messages JMS 
dont ridentifiant est asynchrTuduJms Li stener (©). 



En resume 

Le support JCA de Spring reduit la complexite liee a l'utilisation de FAPI Common Client 
Interface pour les communications sortantes, tout en permettant d'utiliser les connecteurs 
dans et hors des serveurs d' applications. 

Le framework Spring offre egalement un support permettant de configurer les connexions 
ententes pour des connecteurs. Par ce biais, il est notamment possible de mettre en ceuvre des 
observateurs JMS afin d'utiliser les mecanismes asynchrones de communication. 
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Mise en oeuvre de JMS et JCA dansTudu Lists 

La mise en oeuvre de JMS et JCA dans 1' application Tudu Lists permet d'implementer F envoi 
de messages JMS lors de la realisation de taches par le biais d'une file JMS nommee 
tudu. queue. Des applications autonomes sont a Fecoute de ces messages afin d'afficher leurs 
contenus. 

Tudu Lists propose deux approches afin d'implementer cette fonctionnalite. La premiere 
s'appuie sur JMS et la seconde sur JCA. La figure 12-6 illustre les mecanismes mis en oeuvre. 
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Figure 12-6 

Implementation des mecanismes JMS et JCA dans Tudu Lists 



Toutes les classes relatives a la mise en oeuvre de ces technologies sont localisees dans le 
fichier applicationContext-jms.xml du repertoire WEB-INF. 

L application necessite la mise en oeuvre d'un fournisseur JMS. Nous avons choisi d'utiliser 
ActiveMQ a cet effet. Afin de garantir le bon fonctionnement de F application, il est necessaire 
de demarrer ce fournisseur JMS de maniere autonome par Fintermediaire du script startActi- 
veMQ.bat. 



Configuration de I'intercepteur 

Pour ne pas impacter le code de F application existante, nous creons un intercepteur en POA 
afin d'ajouter le mecanisme d'envoi de messages JMS. Nous detaillons F implementation de 
ce composant a la section suivante, relative a Fenvoi des messages JMS. 

Nous appliquons cette entite sur le composant de la couche service metier TodoManager. 
Le tissage de I'intercepteur se realise de la maniere suivante dans le fichier application- 
Context.xml du repertoire WEB-INF : 

<aop:config> 

<aop:aspect id="monAspectbean" ref=" jmsInterceptor"> 
<aop:pointcut id="maCoupe" 
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expression="execution(* *. .TodoManager*.*( . . ))"/> 
<aop:around pointcut-ref="maCoupe" method="notif ier"/> 
</aop:aspect> 
</aop:config> 

Dans la mesure oil nous utilisons le fournisseur JMS ActiveMQ pour echanger des messages 
JMS, il est necessaire de configurer la fabrique de connexions relative a cet outil ainsi que le 
template JMS de Spring et l'intercepteur. 

Cette configuration est localisee dans le fichier applicationContext-jms.xml : 

<bean id="connectionFactory" 

cl ass="org.acti vemq .Acti veMQConnecti on Factory "> 
<property name="brokerllRL" value="tcp://localhost:61616"/> 
</bean> 

<bean id="templ ate" 

cl ass="org.springf ramework. jms.core. JmsTempl ate"> 
<property name="connectionFactory" ref="connecti onFactory"/> 
<property name="defaul tDesti nationName" val ue="tudu. queue" /> 

</bean> 



Envoi des messages 

L'envoi des messages est declenche par l'intercepteur Jmslnterceptor, localise dans le 
package tudu.jms. Avec le support d'AspectJ de Spring, un Bean simple peut etre mis en 
ceuvre. Dans notre cas, la methode noti f i er est executee. 

Cette derniere permet de creer un objet de type TuduMessage, suite a l'execution d'un traite- 
ment pour un todo. Cet objet contient les informations relatives au todo impacte ainsi que 
l'operation realisee. II est cree de la maniere suivante par le biais de la methode 
createTuduMessage de l'intercepteur : 

private TuduMessage createTuduMessage( 

ProceedingJoinPoint invocation) { 
String methodName = invocation. getSignature( ) .getName( ) ; 
Object[] args = invocation. getArgs( ) ; 
if( args[0] instanceof String ) { 
String todold = (String)args[0] ; 



TuduMessage message = new TuduMessage( ) ; 
mes s age. setOperationType( methodName) ; 
message. setTodoId( todold) ; 
return message; 
} else { 

Todo todo = (Todo)args[0] ; 



TuduMessage message = new TuduMessage( ) ; 
mes s age. setOperationType( methodName) ; 
message. setTodoIdt todo. getTodoId( ) ) ; 
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message. setTodoCompl eted(todo . isCompl eted( ) ) ; 
message. setTodoCreationDate(todo.getCreat ion Da te( ) ) ; 
message. setTodoDescri pti on (todo. get Description ( ) ) ; 
message. setTodoPriority(todo. get Priori ty( ) ) ; 
return message; 

} 

} 

Cette approche permet d'intercepter les methodes utilisant des parametres de types String 
(cas de la methode findTodo de l'interface TodosManager) et Todo (cas des methodes 
updateTodo de cette meme interface). 

Une fois l'objet de type TuduMessage cree, le support JMS de Spring est utilise afin de Fencap- 
suler dans un message JMS de type ObjectMessage et de Fenvoyer. Ces traitements sont realises 
de la facon suivante par 1' intermediate de la methode sendMessage de Fintercepteur : 

private void sendMessage(final TuduMessage message) { 
template. send(new MessageCreator( ) { 
public Message createMessage( 

Session session) throws JMSException { 
ObjectMessage ObjectMessage = 

session. createObjectMessage( ) ; 
ObjectMessage. setObject( mess age) ; 
return ObjectMessage; 

} 

}); 

} 

L'intercepteur decrit dans cette section est configure dans le fichier applicationContext- 
jms.xml de la maniere suivante : 

(...) 

<bean id=" jms Interceptor" cl ass-" tudu . jms . Jms Interceptor "> 

<property name="templ ate" ref="templ ate"/> 
</bean> 



Reception des messages 

Tudu Lists offre deux possibilites pour recevoir les messages JMS precedents, toutes deux de 
maniere asynchrone. 

La premiere s'appuie sur le support JMS de Spring et la seconde sur son support JCA. 

La configuration de la premiere se realise de la maniere suivante dans le fichier application- 
Context-listener-jms.xml : 

<bean id="connectionFactory" 

cl ass-" org. act ivemq. Act iveMQConnect ion Factory") 
<property name="brokerURL" value-"tcp://localhost:61616"/> 
</bean> 

<bean id="jmsContainer" class="org.springframework. jms 
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. 1 i stener. Def aul tMessageLi stenerContainer"> 
<property name="connectionFactory" ref="connecti onFactory"/> 
<property name="destinationName" val ue="tudu.queue"/> 
<property name="mess age Li stener" ref="asynchTuduJmsLi stener "/> 
</bean> 

<bean id="asynchTuduJmsLi stener" 

cl ass="tudu. jms . AsynchTuduJmsLi stener "/> 

La configuration de la seconde se realise de la maniere suivante dans le fichier application- 
Context-listener-jca.xml : 

<bean id="resourceAdapter" class="org.springframework. jca 

.support. ResourceAdapter Factory Bean "> 
<property name="resourceAdapter"> 
<bean class="org.apache.activemq 

. ra . Acti veMQResourceAdapter"> 
<property name="serverUrl " 

val ue="tcp: //l ocal host : 61616 "/> 

</bean> 
</property> 

<property name="workManager"> 

<bean cl ass-"org.springf ramework 

. jca .work.Simpl eTaskWorkManager"/> 

</property> 
</bean> 

<bean cl ass="org.springf ramework. jms . 1 i stener 

.endpoint. JmsMessageEndpointManager"> 
<property name="resourceAdapter" ref="resourceAdapter"/> 
<property name-" acti vat ionSpec"> 

<bean class-" org. apache. acti vemq 

. ra .ActiveMQActi vationSpec"> 
<property name="destination" val ue="tudu.queue"/> 
<property name="destinationType" 

val ue="javax. jms . Queue" /> 

</bean> 
</property> 

<property name="ref" value-"asynchTuduJmsListener"/> 
</bean> 

<bean id="asynchTuduJmsLi stener" 

cl ass="tudu. jms .AsynchTuduJmsLi stener "/> 

L'une et 1' autre approches peuvent etre utilisees directement dans une application Java auto- 
nome par l'intermediaire d'une classe du type suivant : 

public class AsynchTuduListenerMain { 
(...) 

public static void main(String[] args) { 
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CI assPathXml Appl i cationContext context=nul 1 ; 
try { 

context=new CI assPathXml Appl i cati onContext( 

getAppl i cationContextFi 1 e( ) ; ) ; 
Thread. sleep(60000) ; 
} catch (Exception ex) { 

(...) 
} finally { 

if( context!=nul 1 ) { 
context . cl ose( ) ; 

} 

} 

System. exit(O) ; 

} 

} 

La methode getAppl i cati onContextFi 1 e renvoie le nom du fichier XML de Spring suivant 
l'approche souhaitee : applicationContext-listener-jms.xml pour l'utilisation du support 
JMS de Spring et applicationContext-listener-jca.xml pour l'utilisation de son support JCA. 



Conclusion 

Java EE propose differentes specifications pour integrer les applications Java/Java EE dans les 
systemes d' information d'entreprise. Les technologies correspondantes sont JMS, afin d'interagir 
avec des middlewares orientes messages, et JCA, afin d'acceder a des applications d'entre- 
prise utilisant diverses technologies. 

Ces specifications ne sont pas d'une utilisation facile dans les applications Java/Java EE, car 
elles impliquent le recours conjoint a des mecanismes synchrones et asynchrones, tout en 
gerant des transactions plus complexes sur plusieurs ressources. 

Spring offre un support pour ces deux technologies permettant de les configurer simplement 
en masquant la complexite de leur utilisation dans les applications. Leur mise en ceuvre avec 
la POA permet de faire interagir des composants existants dans des systemes d' information 
d'entreprise sans impacter le code de ces composants et simplement au moment de l'assem- 
blage de 1' application. 



Partie IV 



Technologies 
d'integration 

Cette partie decrit les technologies et outils permettant a des applications Java/Java EE de 
s'integrer dans des systemes d'information d'entreprise, systemes fondes sur une multitude 
de mecanismes de communication et de technologies heterogenes. 

Le chapitre 13 se penche sur la maniere de mettre en ceuvre des services Web avec Spring 
Web Services. Utilisant une approche par contrats de service et un modele de programma- 
tion similaire a Spring MVC, ce framework rend la mise en ceuvre des technologies XML 
dans les applications Java/Java EE a la fois simple et optimale. 

Le chapitre 14 aborde les problematiques liees a la securite des applications et introduit 
Spring Security. Cet outil offre un cadre generique et flexible permettant d'appliquer 
simplement des regies de securite a une application en s'abstrayant des approches et techno- 
logies utilisees. 

Le chapitre 15 traite des aspects relatifs aux traitements batch. Bien que ce type de traite- 
ment soit omnipresent en entreprise, peu d' outils Open Source permettent de les mettre en 
ceuvre. Le portfolio de Spring propose a cet effet l'outil Spring Batch, qui fournit un cadre 
adapte aux developpements d' applications de type batch. 
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Dans ce chapitre, nous allons aborder la maniere de mettre en ceuvre des services Web en se 
fondant sur le framework Spring Web Services (WS), Foutil dedie du portfolio de Spring. 

Presente a ses debuts comme une solution miracle pour F integration des donnees, le XML se 
revele une technologie d'usage complexe, souvent peu performante, mais surtout surcharged 
d'une plethore de normes obscures. 

L'informatique d'entreprise est envahie de concepts tels que SOA ou les services Web adjoints 
au XML. Nous allons definir ces termes, ainsi qu'en montrer les aspects utiles en matiere 
d' architecture logicielle et en detailler les principales normes, SOAP et WSDL en particulier. 

En fin de chapitre, nous donnerons un exemple de mise en ceuvre de Spring WS en publiant 
dans Tudu Lists des Beans Spring en tant que services Web par Fintermediaire d'endpoints. 

Les services Web 

Les services Web, ou Web Services, sont un ensemble de specifications, particulierement 
complexes, visant a faire communiquer des applications distantes via un format XML standar- 
dise. 

La Web Services Interoperability Organization propose une specification complete, nommee 
Basic Profile, qui garantit qu'un service Web peut etre utilise sans probleme, quel que soit le 
langage de programmation utilise. Cette specification, ainsi qu'un outil permettant de verifier 
la conformite d'un service Web, est disponible sur le site Web de F organisation, a Fadresse 
http://www.ws-i.org/. 

Cette technique d' integration de systemes est souvent couplee au concept de SOA (Service 
Oriented Architecture). Le style d' architecture SOA prone la creation d' applications developpees 
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en couches, avec une couche metier mise a la disposition d'autres applications. En ce sens, 
une application Spring est une candidate toute designee pour faire du SOA, puisqu'il s'agit 
d'offrir un acces a la couche metier. 

Les services Web ne sont toutefois qu'un moyen parmi d'autres de publier des services metier 
distants. Si nos applications sont toutes developpees en Java, par exemple, Futilisation de 
RMI est a la fois plus simple et plus efficace que celle des services Web. Spring supporte en 
outre d'autres protocoles, comme Burlap et Hessian, qui sont eux aussi plus performants que 
les services Web classiques. 

Reste que Futilisation de services Web est un bon moyen de publier une couche metier de maniere 
independante du langage d' implementation, tout en suivant les standards actuels du marche. 



Concepts des services Web 

Les services Web s'appuient sur une trentaine de specifications, dont nous ne detaillons ici que 
les deux principales, SOAP et WSDL. Ces specifications sont toutes emises par le W3C (World- 
Wide Web Consortium) et sont par consequent des standards internationaux largement reconnus. 

SOAP signifiait a l'origine « Simple Object Access Protocol » (le nom complet n'est plus 
utilise). II s'agit d'un protocole permettant de decrire des objets dans un format XML, afin de 
pouvoir echanger ces objets via Internet. 

Les applications SOAP utilisent essentiellement le protocole HTTP pour effectuer ces echan- 
ges d'objets, mais elles peuvent egalement utiliser d'autres protocoles, comme SMTP ou 
JMS. Malgre son nom d'origine, SOAP n'est pas un standard simple d' utilisation. II a de plus 
le defaut d'etre particulierement lent, la transformation d'objets en XML etant un mecanisme 
intrinsequement couteux en ressources. 

WSDL (Web Services Description Language) — prononcez wizzdle — decrit de quelle 
maniere il est possible d'utiliser un service Web (protocole a utiliser, methodes accessibles, 
objets utilises). L'obtention d'un document WSDL est essentielle pour utiliser un service 
Web, car c'est ce document qui en donne le « mode d'emploi ». II peut etre lu par un logiciel 
pour generer automatiquement un client au service Web qu'il decrit, faisant ainsi office de 
specification technique. 

Les deux specifications que nous venons de decrire sont relativement complexes, mais il n'est 
heureusement nul besoin de les apprendre pour les utiliser. Un ensemble d'outils performants 
permet de lire et d'ecrire du SOAP et du WSDL a notre place. Ces outils ont le double avan- 
tage de faire gagner beaucoup de temps (il faut compter une heure pour lire ou ecrire un 
service Web simple) et de garantir le respect des specifications. 



Spring WS 

Comme nous venons de le voir, les services Web se fondent sur une multitude de normes 
complexes, dont les deux principales sont SOAP et WSDL. L utilisation de ces services n'est 
done pas evidente et entraine des contraintes importantes en termes d'interoperabilite et de 
performances. 
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Pour remedier a ces difficultes, la communaute Spring offre le framework Spring WS, qui 
permet de mettre en ceuvre et d'appeler des services Web simplement en se fondant sur les 
principes de Spring, tels que l'injection de dependances, le modele de programmation de 
Spring MVC fonde sur des annotations et le concept de template. 

Ce framework fait preuve d'une grande flexibilite lors de F exposition de services Java exis- 
tants en tant que services Web. II laisse notamment le choix des briques utilisees, et les 
supports offerts sont simples d'utilisation. 

L'approche dirigee par les contrats 

Deux approches sont envisageables pour mettre en ceuvre des services Web suivant la maniere 
dont les frameworks de services sont implemented : 

• Approche dirigee par les contrats de services. Consiste a realiser la definition des 
services en premier en se fondant sur la technologie WSDL. Cette derniere utilise le 
XML et un ou plusieurs schemas XML afin de decrire les messages echanges ainsi que 
les operations et les proprietes des services. A partir de cette description, le framework de 
services Web peut soit generer les ressources correspondantes, soit deduire les entites a 
appeler. 

• Contrats de service deduits d' interfaces Java. Correspond a la construction automatisee 
du contenu XML des contrats de services en fonction des interfaces Java de description 
des services. Pour que la definition WSDL reste bien generique, il convient de faire 
attention a ne pas utiliser d'entites specifiques au langage d' implementation dans les 
contrats. 

La mise en ceuvre des services Web induit la coexistence d'un paradigme XML avec un para- 
digme objet. Cela necessite de convertir des elements XML en objets Java, et inversement, 
tout en devant gerer les imbrications d'elements XML entre eux et les graphes d'objets. Bien 
que ces conversions puissent paraitre simples de prime abord, leur mise en ceuvre se revele 
complexe, car, a l'instar du mapping objet/relationnel dans le contexte des bases de donnees, 
les deux technologies possedent des differences fondamentales. 

Les principales difficultes de ces conversions sont les suivantes : 

• Certains types Java, tels que les collections, n'ont pas de correspondance dans la techno- 
logie XML. Pour les collections, il est conseille d' utiliser des tableaux. 

• Les cycles entre les objets contribuent a complexifier la mise en ceuvre du contenu XML 
correspondant. Pour rester optimale, la mise en ceuvre des references au niveau du XML 
doit etre envisagee, mais au prix d'une complexification du contenu XML. 

Dans ce contexte, la conversion automatique n'est pas toujours appropriee. De ce fait, l'utili- 
sation de la seconde approche souffre de differents inconvenients lors de la mise en ceuvre de 
services Web, notamment les suivants : 

• Comme les contrats des services XML sont lies aux interfaces, ils peuvent evoluer si ces 
dernieres evoluent, et il n'est des lors plus possible de decorreler les uns des autres. 
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• La transformation automatique d'interfaces Java et de fichiers WSDL peut souffrir de 
problemes de performances. 

• La deduction des contrats ne permet pas de reutiliser les types mis en ceuvre puisqu'ils ne 
sont pas definis dans des fichiers de definition XML (XSD ou XML Schema Definition) 
independants. 

• L'approche se fondant sur les interfaces Java permet difficilement la cohabitation de diffe- 
rentes versions de services Web. 

Au vu de ces differents elements, Spring WS a adopte l'approche dirigee par les contrats de 
services et ne supporte pas la seconde. 

Mise en ceuvre de services 

Afin d'exposer des services Web a partir d'un serveur, Spring WS met en ceuvre une chaine 
generique et extensible d' entites de traitement des requetes completement independante de la 
technologie de transport des messages SOAP choisie. 

La figure 13-1 illustre les differentes entites utilisees par le framework afin d'implementer ces 
mecanismes. 
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Figure 13-1 

Entites de traitement des requetes de Spring WS 



Ces entites, qui constituent le cceur de Spring Web Services, possedent les caracteristiques 
suivantes : 

• MessageDispatcher : entite centrale du framework permettant d'implementer la mecanique 
de traitement des requetes en se fondant sur les entites EndpointMapping et Endpoint- 
Adapter. Elle integre egalement des mecanismes extensibles d'aiguillage et de gestion des 
exceptions. En interne, l'entite se fonde sur un contexte de message correspondant a une 
representation des messages independante de la technologie de transport. 

• EndpointMapping : definit les strategies d'aiguillage afin d'acceder aux unites de traitement 
de la requete. 
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• Endpoi ntAdapter : entite d' adaptation des traitements avant l'appel de Fendpoint pennettant de 
rendre extensible la maniere d'appeler ces entites de traitement. 

• Endpoi nt : entite de traitement d'un appel de service Web offrant Faeces aux informations 
presentes dans la requete et ayant la responsabilite de retourner eventuellement des infor- 
mations suite aux traitements. Elle permet habituellement de rendre un service accessible 
de maniere distante par F intermediate de la technologie SOAP. 

Spring WS utilise les concepts de base de Spring, telles que F injection de dependances, pour 
configurer ces entites decrites. 

Configuration 

Avant de pouvoir acceder aux services, une infrastructure generate doit etre configuree. Elle 
permet notamment de preciser la technologie de transport souhaitee. Le protocole HTTP etant 
le plus utilise lors de la mise en ceuvre des services Web, nous allons le decrire principale- 
ment. Les differentes couches de transport utilisables sont abordees a la section « Gestion des 
transports ». 

La classe MessageDi spatcherServl et fournit le point d' entree dans F application Web exposant 
des services Web. Comme il s'agit d'une servlet, il convient de la configurer de maniere 
classique dans le fichier web.xml, comme dans le code suivant : 

<web-app> 
(...) 

<servl et> 

<servlet-name>tudu-ws</servl et-name> 
<servlet-class> 

org. springf ramework.ws .transport . http*» 
.MessageDi spa tcherServlet 

</servl et-cl ass> 
</servlet> 

<servl et-mappi ng> 

<servlet-name>tudu-ws</servl et-name> 

<url -pattern>/*</url -pattern> 
</servlet-mapping> 
</web-app> 

A Finstar de la servlet Di spatcherServl et de Spring MVC, cette servlet met en ceuvre impli- 
citement un contexte applicatif Spring. Par defaut, la configuration de ce contexte se realise 
dans un fichier dont le nom correspond au nom de la servlet suffixe par -servlet.xml et qui est 
localise dans le repertoire WEB-INF de Fapplication Web. Avec Fexemple ci-dessus, le nom 
de ce fichier est tudu-ws-servlet.xml. 

Toutes les configurations de Beans que nous decrivons dans la suite doivent etre specifiees a 
ce niveau. 



Technologies d'integration 

Partie IV 



Contrat des services 

Comme Spring WS offre une approche dirigee par les contrats, la premiere etape dans la mise 
en ceuvre de services consiste en la definition de leurs contrats. 

Les structures manipulees sont definies a Faide de la technologie XSD (XML Schema Definition). 

Le code suivant decrit la definition d'un message (Q) et d'une structure permettant de conte- 
nir une liste de todos (Q) : 

<xs : schema xml ns :xs="http: //www. w3.org/2001/XMLSchema" 

xml ns : tudu="http: //sou reef orge.net/tudu/schemas" 
el ementFormDef aul t="qual if ied" 

target Namespace="http: //sourcef orge.net/tudu/schemas"> 
(...) 

<xs : el ement name=" GetTodos Response "><—© 
<xs : compl exType> 
<xs:all> 

<xs:element name="Todos" type="tudu:TodoType"/> 
</xs:all> 
</xs: compl exType> 
</xs:element> 

<xs : compl exType name="TodoType"><— Q 
<xs : sequence> 

<xs:element name="TodoId" type="xs:string"/> 
<xs:element name="Description" type="xs : stri ng"/> 
<xs:element name="Priority" type="xs:int"/> 
<xs:element name="Compl eted" type="xs:boolean"/> 
<xs:element name="CreationDate" type="xs :date"/> 
</xs : sequence) 
</xs: compl exType> 
</xs : schema> 

Une fois la definition de la structure des messages realisee, il convient de configurer Spring 
WS et d'exposer la definition du service correspondant au format WSDL. 

La classe SimpleXsdSchema permet de charger le fichier XSD defini. Cette classe s'appuie sur 
les mecanismes de chargement des ressources de Spring par 1' intermediate de sa propriete 
xsd, comme le montre le code suivant : 
<bean id="schema" 

cl ass="org.springf ramework.xml .xsd.SimpleXsdSchema"> 
<property name="xsd" value="/WEB-INF/tudu.xsd" /> 
</bean> 

Spring WS offre une fonctionnalite interessante permettant de deduire la description 
WSDL du service en se fondant sur le fichier XSD configure precedemment et la classe 
DefaultWsdlllDefinition. Cette derniere cree automatiquement des messages de requete 
et de reponse pour tous les elements element trouves dans le fichier XSD, puis construit 
les operations avec les suffixes Request pour la requete et Response pour la reponse. 
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Ces suffixes peuvent etre modifies ail moyen des proprietes requestSuffix et 
responseSuf f ix de la classe. 

Les autres informations, telles que le type de port, Fespace de nommage et l'adresse d'acces 
doivent etre specifies par les proprietes portTypeName (0), targetNamespace (Q) et 
locationUri (Q) de la classe : 

<bean id="tudu" class="org.springframework.ws.wsdl 

.wsdlll.DefaultWsdlllDef1n1t1on"> 
<property name="schema" ref="schema"/> 
<property name-"portTypeName" val ue="Tudii"/><— Q 
<property name="locationllri Q 

val ue="http: //l ocal host : 9080/ tudu-ws/ tuduService/"/> 
<property name=" target Names pa ce"<— © 

val ue="http://tudu.sourceforge.net/tudu/definitions"/> 

</bean> 

<bean id="schema" 

cl ass="org. springf ramework.xml . xsd . Simpl eXsdSchema"> 
<property name="xsd" value="/WEB-INF/tudu.xsd"/> 
</bean> 

La valeur de la propriete locationUri peut correspondre a une adresse relative. L'adresse 
absolue correspondante est ensuite automatiquement generee dans le fichier WSDL. 

Spring WS permet de definir a la main le fichier WSDL a l'aide de la classe 
SimpleWsdlllDefinition, qui a la responsabilite de le charger. La reference du fichier se 
realise par 1' intermediate de son constructeur, comme dans le code suivant : 

<bean id="tudu" class="org.springframework.ws 

.wsdl .wsdl 11 .Simpl eWsdl HDefinition"> 
Constructor- a rg val ue="/WEB- INF/wsdl /tudu.wsdl "/> 
</bean> 

Spring WS rend automatiquement accessible de maniere distante la definition WSDL associee 
a chaque Bean construisant un contrat de services Web. Afin de determiner l'adresse, le 
framework utilise le nom du Bean de definition et le suffixe par .wsdl. Dans notre cas et 
avec le protocole HTTP, le fichier WSDL defini precedemment est accessible depuis 
l'adresse http://<serveur>:<port>/<module>/tudu.wsdl. 



Acces aux endpoints 

Une fois les unites de traitement mises en ceuvre, le mecanisme d'aiguillage des requetes de 
Spring WS doit etre configure vers la bonne unite de traitements. Completement independant 
de la technologie de transport utilisee, ce mecanisme integre differentes approches de selection 
fondees sur les informations contenues dans la requete. 
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Le tableau 13-1 recapitule les approches d'acces aux endpoints utilisables avec Spring WS 
selon l'approche considered. 



Tableau 13-1. Approches d'acces aux endpoints supportees par Spring WS 



Approche 


Description 


Payl oadRootQNameEndpointMapping 


Utilise le nom qualifie correspondant au nceud racine present dans le 
message pour determiner I'entite de traitement. 


SoapActionEndpointMappi ng 


Utilise la valeur de I'en-tete HTTP SOAPAction de la requete pour 
determiner I'entite de traitement (speoifique a la version 1 .1 de SOAP). 


MethodEndpointMappi ng conjointement 
utilisee avec des annotations 


Utilise I'annotation PayloadRoot ou SoapAction pour selectionner la 
methode a appeler. 


Si mpl eActi onEndpoi ntMappi ng 


Utilise les en-tetes de WS-Adressing pour determiner I'entite de traite- 
ment. 



L'approche la plus repandue consiste a utiliser la classe Payl oadRootQNameEndpointMapping en 
se fondant sur sa propriete mappings de type Properties arm de specifier la correspondance 
entre les noms qualifies et les identifiants des Beans de traitements. 

Les noms qualifies doivent etre exprimes selon la syntaxe suivante : {URI de 1 'espace de 
nommageKnom de baliseX 

Pour une requete recuperant une liste de todos, le nom qualifie est done de la forme { http : // 
tudu.sourceforge.net/tudu/definitions}TodoRequest. 

Le code suivant illustre l'utilisation de la propriete mappings (Q) de la classe pour preciser le 
mapping des requetes (Q) : 

<beans> 



<bean cl as s=" o rg. springf ramework.ws .server .endpoint 

.mapping. Payl oadRootQNameEndpoi ntMappi ng"> 
<property name="mappings"><— Q 
<props> 

<prop key=" {http: //sourcef orge.net /tudu<—@ 
/schemaslGetTodoLi sts Request "> 
todoListsEndpoint 
</prop> 

<prop key=" {http: //sourcef orge.net /tudu<—@ 
/s enema s}GetTodos Request") 
todosEndpoint 
</prop> 
</props> 
</property> 
</bean> 
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<bean id="todosEndpoint" 

class="tudu.web.ws . endpoint .TodosEndpoint"> 
<property name="todosManager" ref="mockTodosManager"/> 
</bean> 

<bean id="todoListsEndpoint" 

cl ass="tudu. web. ws.endpoint .TodoLists Endpoint "> 
<property name="todoLi stsManager" ref="todol_i stsManager"/> 
</bean> 
<beans> 

L'approche fondee sur la classe SoapActionEndpointMapping s'utilise de maniere similaire, si 
ce n'est que les cles de la propriete mappings sont ici les valeurs possibles de l'en-tete HTTP 
SOAPAction. Cette approche n'est utilisable qu'avec un transport HTTP. 

Le code suivant illustre la mise en ceuvre de la classe SoapActionEndpointMapping : 
<beans> 

<bean id="endpointMapping" cl ass-"org.springf ramework.ws.soap 
.server.endpoint.mapping.SoapActionEndpointMapping"> 
<property name="mappings"> 
<props> 

<prop key=" {http: //sourcef orge.net/tudu 

/schemaslGetTodoLists Request "> 
todoListsEndpoint 
</prop> 

<prop key=" {http: //sourcef orge.net/tudu 
/schema s}GetTodosRequest"> 
todosEndpoint 
</prop> 
</props> 
</property> 
</bean> 

(...) 

</beans> 

Pour activer l'utilisation des annotations afin de selectionner les methodes de traitement 
correspondant a la requete, une approche d'acces aux endpoints configuree avec des annota- 
tions peut etre specifiee. Les deux principales entites de ce type correspondent aux classes 
suivantes : 

• PayloadRootAnnotationMethodEndpointMapping, qui permet d'utiliser Fannotation PayloadRoot 
pour se fonder sur le nom qualifie du nceud racine du message. 

• SoapActionAnnotationMethodEndpointMapping, qui permet d'utiliser l'annotation 
SoapAction pour se fonder sur la valeur de l'en-tete HTTP SOAPAction. 

La classe MessageMethodEndpointAdapter doit egalement etre configuree a ce niveau afin de 
pouvoir permettre un aiguillage vers des methodes particulieres d'un endpoint. 
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La configuration de cette classe se realise simplement sous forme de Beans de la facon 
suivante : 

<beans> 
(...) 

<bean cl as s=" org.springf ramework.ws. server. endpoint 

.mapping. Pay loadRootAnnotationMet hod EndpointMapping"/> 

<bean cl as s=" org.springf ramework.ws. server. endpoint * 

.adapter .Mess ageMet hod Endpoint Adapter "/> 

(...) 
</beans> 

Une fois la strategic choisie, la mise en ceuvre des annotations correspondantes doit etre reali- 
see dans la classe de Fendpoint. Avec Fannotation PayloadRoot, les proprietes localPart et 
namespace sont supportees afin de specifier respectivement le nom de la balise et FURI de 
Fespace de nommage. Dans le cas de Fannotation SoapAction, sa valeur correspond au 
contenu de Fen-tete HTTP SOAPHeader. 

Pour ces deux annotations, et en cas de correspondance avec les proprietes, la methode sur 
laquelle est appliquee Fannotation est utilisee afin de traiter la requete SOAP. 

Le code suivant illustre la mise en ceuvre de Fannotation Payl oadRoot (Q) afin de definir une 
methode d'un endpoint en tant que methode de traitement : 

@Payl oadRoott 1 ocal Part = "GetTodol_istsRequest",<— Q 

namespace = "http://sourceforge.net/tudu/schemas") 
public GetTodoLi stsResponse getTodoLi sts( 

GetTodoListsRequest request) { 

(...) 

} 

Unites de traitement 

Dans Spring WS, les entites centrales correspondent aux endpoints puisque ce sont elles qui 
definissent les traitements a executer pour une requete SOAP. 

Le framework definit trois approches principales dans la mise en ceuvre des endpoints : 

• DOM ou technologie apparentee. Approche la plus simple, dans laquelle les traitements de 
Fendpoint se situent au plus pres des donnees XML des messages. Elle approche met en 
ceuvre des technologies permettant de manipuler XML avec une API DOM ou apparentee. 

• Mapping XML/objet. Approche plus elaboree, dans laquelle les traitements des endpoints 
utilisent des objets dont le contenu est initialise automatiquement a partir des messages 
XML (et inversement pour la reponse). 

• Annotations. Utilise des annotations pour specifier des methodes de traitement des 
endpoints. La signature de ces methodes est flexible et peut s'adapter aux besoins d'utilisation 
pour les methodes des endpoints. 
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Pour la premiere approche, Spring WS supporte un ensemble de classes abstraites permettant 
d'acceder aux donnees de la requete avec DOM ou une technologie apparentee et d'ecrire la 
reponse avec cette meme technologie. 

Le tableau 13-2 recapitule les classes abstraites permettant d'acceder aux donnees contenues 
dans le payload et utilisables a ce niveau. 



Tableau 13-2. Classes abstraites d'acces aux donnees supportees par Spring WS 



Classe 




AbstractDomPayl oadEndpoint 


Utilise les API DOM standards pour parcourir une representation en 
memoire du XML. 


AbstractJDomPayl oadEndpoint 


Utilise les API JDOM. 


AbstractDom4jPayl oadEndpoint 


Utilise les API DOM4J. 


AbstractXomPayl oadEndpoint 


Utilise les API XOM. 


AbstractSaxPayl oadEndpoint 


Utilise les API SAX selon une approche evenementielle. 



Dans ce contexte, un endpoint correspond a une classe etendant une des classes decrite au 
tableau 13-2. Cette specialisation entraine 1' implementation d'une methode protegee accep- 
tant en parametre la representation du message recu dans la technologie choisie et retournant 
un message pour la reponse. Ce dernier doit etre construit en se fondant sur les traitements 
realises. Si aucune donnee ne doit etre retournee, la valeur nul 1 est specifiee. 

Dans l'exemple ci-dessous, nous decrivons l'utilisation de Foutil JDOM. L' extension de la 
classe abstraite AbstractJDomPayl oadEndpoint (0) necessite 1' implementation de la methode 
invokelnternal (©), qui possede la signature precedemment decrite. II est a noter que l'outil 
supporte les chemins XPath (Q) afin d'acceder aux donnees presentes dans la requete. 

public class JDomTodoLi stsEndpoint 

extends AbstractJDomPayloadEndpoint {<— O 
private TodoLi stsManager todoListsManager; 

private Namespace namespace; 
private XPath userIdExpression;<— Q 

public TodoListsEndpointO throws JDOMException { 
namespace = Namespace. getNamespace( "tudu" , 

"http: //sourcef orge.net /tudu/schemas" ) ; 
userldExpression = XPath .newlnstance( "//tudu:UserId" ) ; 
user I dExpres si on .addNamespace( namespace) ; 

} 

protected Element invokelnternal 

Element request) throws Exception { 
String userld = userldExpression. val ueOf( request) ;<— © 



Set<TodoLi st> todoLists 
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= todo Li stsManager.findBy Login (user Id) ; 

Element response = new Element( 

"GetTodoLi stsResponse" , namespace) ; 
for (TodoList todoList : todoLists) { 
Element todoListElement 

= new El ement( "TodoLi st" , namespace); 

Element 1 i stldEl ement 

= new ElementCListld" , namespace); 
1 i stldEl ement .setText( todoList .get Li stld ( ) ) ; 
todo Li stEl ement . addContent( 1 i stldEl ement) ; 

Element nameEl ement = new El ement( "Name" , namespace); 
nameEl ement . setText( todo Li st. get Name ( ) ) ; 
todo Li stEl ement . addContent( nameEl ement) ; 

Element rssAl 1 owedEl ement = new Element( 

"RssAllowed", namespace); 
rssAl 1 owed El ement .setText( 

remoteTodoList.isRssAllowedO? "true" : "false"); 
todo Li stEl ement . addContent( rssAl 1 owedEl ement) ; 

Element 1 astUpdateEl ement = new Element( 

"LastUpdate" , namespace); 

1 astUpdateEl ement .setText( 

remoteTodoLi st. get LastUpdate ( ) .toStri ng( ) ) ; 
todo Li stEl ement . addContent( 1 astUpdateEl ement) ; 

response. addCon tent (todo Li stEl ement) ; 

} 

return response; 

} 

(...) 

} 

Avec l'approche par mapping des donnees XML dans des objets Java simples, l'implementa- 
tion des endpoints devient completement independante des technologies XML. Un Bean 
contenant les donnees de la requete est specifie en parametre de la methode, et un objet peut 
etre retourne afin de specifier les donnees de la reponse. 

Spring WS propose a cet effet des entites implementant les interfaces Marshal ler et 
Unmarshal 1 er. Ces dernieres ont la responsabilite de convertir un contenu XML en un objet et 
inversement. Le framework offre differentes implementations fondees sur les frameworks de 
mapping XML/objet du marche. Nous detaillons la mise en ceuvre de ces entites a la section 
« Mapping des donnees ». 
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Afin d'utiliser cette fonctionnalite au niveau des endpoints, la classe abstraite Abstract- 
Marshal 1 ingPayloadEndpoint doit etre specifiee en tant que classe mere des endpoints. Cette 
classe dispose des attributs marshal 1 er et unmarshal 1 er permettant de specifier ces deux enti- 
res de mapping. Les classes de Spring WS suffixees par Marshal 1 er implementent conjointement 
les interfaces Marshal ler et Unmarshal 1 er. 

Le code suivant illustre la mise en ceuvre d'un endpoint utilisant le mapping de donnees par le 
biais de la classe AbstractMarshall ingPayloadEndpoint (Q) et de son point d' entree 
invokelnternal (Q) : 

public class MashallingTodoListsEndpoint 

extends AbstractMarshallingPayloadEndpoint {<— O 
private TodoLi stsManager todoListsManager; 

protected Object invokelnternal ( 

Object o) throws Exception {<— Q 
GetTodoLi stsRequest request = (GetTodoListsRequest) o; 
String userld = request. getllserld( ) ; 



Set<TodoLi st> todoLists 

= todoListsManager. findByLogin(userld) ; 

Set<RemoteTodoLi st> remoteTodoLi sts 

= RemoteTodoLi stUti Is. convert (todoLists) ; 



GetTodoLi stsResponse response = new GetTodoLi stsResponse( ) ; 
res ponse.setTodoLi sts (remoteTodoLi sts) ; 
return response; 



(...) 

} 

Dans ce code, les classes GetTodoLi stsRequest et GetTodoLi stsResponse permettent de mapper 
respectivement les donnees de la requete et de la reponse. Nous les detaillons plus loin dans ce 
chapitre. 

Comme l'illustre le code suivant, l'entite de mapping (Q) doit etre injectee dans l'endpoint 
par Fintermediaire des proprietes marshal ler et unmarshal ler (Q) : 

<bean id="todoListsEndpoint" 

cl as s-"tudu. web. ws .endpoint .Mas ha 1 1 ingTodoLi stsEndpoint"> 
<property name=" todoListsManager" ref="mockTodoLi stsManager "/> 
<property name="marshal 1 er" ref="castorMarshal 1 er"/><— Q 
<property name="unmarshal 1 er" ref="castorMarshal 1 er"/><— Q 

</bean> 

<bean id="castorMarshaller"<— Q 

cl ass="org.springf ramework.oxm. castor. CastorMarshal ler"> 
(...) 
</bean> 
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L'approche fondee sur les annotations apporte une flexibilite interessante dans la mise en 
ceuvre des endpoints puisqu'elle permet de definir plusieurs methodes de traitement pour un 
meme endpoint tout en integrant Faeces simple aux parametres presents dans la requete et le 
mapping XML/objet. 

Les classes de ce type doivent posseder l'annotation Endpoint et utiliser les annotations 
PayloadRoot ou SoapAction en fonction de la strategie choisie. Nous avons decrit leur utilisation 
precedemment, a la section « Acces aux endpoints ». 

En complement de tout cela, Spring WS utilise le modele de programmation de Spring MVC, 
qui permet de passer directement aux methodes des endpoints des elements presents dans la 
requete a Faide de l'annotation XPathParam. La valeur de cette derniere correspond a une 
expression XPath permettant de recuperer F element correspondant. 

Le code suivant illustre Futilisation de l'annotation XPathParam (Q) pour acceder a un 
element de la requete SOAP par Fintermediaire d'un parametre de methode : 

@Payl oadRoot( 1 ocal Part = "GetTodoLi stsRequest" , 

namespace = "http://sourceforge.net/tudu/schemas") 
public void getTodoLists( 

@XPathParam("//tudu:UserId")<— Q 

String userld) throws Exception { 

(...) 

} 

Comme Findique le code suivant, Fentite XpathParamAnnotationMethodEndpointAdapter doit 
etre specifiee dans la configuration afin de definir Fespace de nommage tudu (Q) utilise dans 
l'annotation XPathParam precedente : 

<bean cl ass=" org. springf ramework.ws. server. endpoint 

.adapter . XPath Pa ramAnnotati onMet hod Endpoint Adapter "> 
<property name="namespaces"> 
<props> 

<prop key="tudu"><— Q 

http://sourceforge.net/tudu/schemas 
</prop> 
</props> 
</property> 
</bean> 

Une ou plusieurs entites d' adaptation pour Faeces aux endpoints doivent en outre etre speci- 
fiees. Elles permettent de definir la maniere d' acceder aux methodes de traitement des endpoints. 
Pour pouvoir utiliser les annotations PayloadRoot, les classes MessageMethodEndpointAdapter et 
PayloadRootAnnotationMethodEndpointMapping doivent etre configurees en tant que Beans 
Spring : 

<bean cl ass=" org. springf ramework.ws .server. endpoint 

.mapping. Pay load Root AnnotationMet hod EndpointMapping"/> 

<bean cl ass-" org. springf ramework.ws. server. endpoints 

.adapter .Mess ageMet hod Endpoint Adapter "/> 
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Cette approche offre la possibilite d'utiliser les entites de mapping des donnees decrites prece- 
demment. A cet effet, une autre entite d' adaptation doit etre configuree en complement. Cette 
derniere coiTespond a la classe GenericMarshal 1 ingMethodEndpointAdapter et accepte les attri- 
buts marshal"! er et unmarshal 1 er au niveau de Finjection des entites, comme le montre le code 
suivant : 

<bean cl ass-" org. springf ramework.ws. server. endpoint * 

. adapter . Generi cMarshal 1 ingMethodEndpointAdapter"> 

<property name="marshal 1 er" ref="castorMarshal 1 er"/> 

<property name="unmarshal 1 er" ref="castorMarshal 1 er"/> 
</bean> 

<bean id="castorMarshaller" 

cl as s=" org. springf ramework.oxm. castor. Cas to rMarshal ler"> 
(...) 
</bean> 

Les methodes annotees de traitement des endpoints acceptent directement l'objet mappe et 
peuvent eventuellement en retourner un. Desormais, ces entites sont utilisables directement 
par type, et plus aucun transtypage n'est necessaire. 

Le code suivant illustre la mise en ceuvre d'un endpoint de ce type possedant plusieurs methodes 
de traitement annotees (Q) : 

©Endpoint 

public class TodoListsEndpoint { 

private TodoLi stsManager todoListsManager; 

©PayloadRootdocalPart = "GetTodoListsRequest" , 

namespace = "http://sourceforge.net/tudu/schemas") 
public GetTodoLi stsResponse getTodoLi sts(<— Q 

GetTodoListsRequest request) { 

(...) 

} 

@PayloadRoot(localPart = "GetTodoListRequest" , 

namespace = "http://sourceforge.net/tudu/schemas") 
public GetTodoLi stResponse getTodoLi st(<— © 

GetTodoListRequest request) { 

(...) 

} 

(...) 

} 



Mapping des donnees 

Plutot que de manipuler directement les donnees re?ues et a renvoyer en XML, Spring WS 
offre la possibilite d'utiliser une technologie de mapping XML/objet directement au sein des 
endpoints. 
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La methode de traitement recoit en parametre un objet contenant les donnees de la requete et 
independant de XML. Cette methode peut ensuite renvoyer les donnees de la reponse egalement 
sous forme d'objets. 

Le framework propose deux interfaces pour deflnir ces comportements : Marshal ler et 
Unmarshal 1 er. 

Linterface Marshal ler permet de convertir un objet en XML par F intermediate de sa 
methode marshal, laquelle cree le contenu dans un objet de type Result correspondant a une 
abstraction de flux de sortie XML. 

Le code suivant decrit le contenu de Finterface Marshal 1 er : 

public interface Marshaller { 

void marshal (Object graph, Result result) 
throws XmlMappingException, IOException ; 

} 

Linterface Unmarshal ler correspond au traitement inverse, qui permet de convertir du contenu 
XML en objets par F intermediate de la methode unmarshal de l'interface. Cette derniere 
permet a partir d'un objet de type Source correspondant a une abstraction de flux d'entree 
XML, de creer un objet avec les donnees correspondantes. 

Le code suivant decrit le contenu de Finterface Unmarshal ler : 

public interface Unmarshaller { 

Object unmarshal (Source source) 

throws XmlMappingException, IOException; 

} 

Bien que ces interfaces acceptent de simples objets, les implementations des interfaces prece- 
demment decrites comportent des restrictions induites par les technologies et outils mis en 
ceuvre. II est done parfois necessaire de specifier des fichiers de mapping ou de generer des 
classes. 

Bien que ces entites soient mises en ceuvre par Spring WS, elles peuvent etre utilisees inde- 
pendamment de la technologie des services Web. Le code suivant illustre ce type de mise en 
ceuvre afin de creer du contenu XML a partir d'un objet (Q) et inversement (Q) : 

Marshaller marshaller = (...); 
Unmarshaller unmarshaller = (...); 

//Creation d'un contenu XML a partir d'un objet 
Fi 1 eOutputStream os = null; 
try { 

MaClasse objet = initial isation( ) ; 
os = new Fi 1 eOutputStream( "" ) ; 

marshaller. marshal (objet, new StreamResult(os) ) ;<— Q 
} finally { 

closeOutputStream(os) ; 

} 



//Creation d'un objet a partir d'un contenu XML 
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Fi 1 elnputStream is = null; 
try { 

is = new Fil eInputStream( "" ) ; 

MaClasse objet = unmarshal 1 er . unmarshal (<— Q 

new StreamSource(is)) ; 

} finally { 

close Input St ream(is) ; 

} 



Mapping des donnees 

Avec Spring 3.0, ce support de mapping des donnees XML a ete integre dans le framework Spring lui- 
meme avec le nom Spring OXM. II s'agit d'un module, au meme titre que Spring DAO, JDBC ou AOR 



Spring WS fournit differentes implementations des interfaces Marshal ler et Unmarshal ler 
correspondant aux differentes technologies de mapping XML/objet. Ces technologies suppor- 
ters par Spring WS sont recapitulees au tableau 13-3. 



Tableau 13-3. Technologies de mapping XML/objet supportees par Spring WS 



Technologie 


Description 


JAXB 1 et 2 


Outil de Sun mis en ceuvre par la JSR 222 pour generer des classes Java a partir de schemas 
XML. 


Castor XML 


Outil permettant de realiser le mapping XML/objet en se fondant sur un fichier de configuration 
XML (disponible a I'adresse http://castor.org/xml-framework.html). 


XML Beans 


Outil de mapping objet/XML possedant un support complet de XML Schema et dans lequel les 
classes sont generees avec les informations de mapping (disponible a I'adresse http://xml- 
beans. apache, org/). 


JiBX 


Outil similaire aux outils de mapping objet/relationnel mais pour XML qui utilise I'ajout de proxy 
au niveau des classes mappees de maniere transparente (disponible a I'adresse http:// 
jibx. sourceforge. net/). 


XStream 


Outil consistant en une simple bibliotheque permettant de convertir du XML en objet sans aucune 
configuration (disponible a I'adresse http://xstream.codehaus.org/). 



Nous allons detailler la mise en ceuvre de Castor XML au niveau des endpoints. La premiere 
etape consiste a initialiser l'entite permettant de realiser la conversion avec cet outil. Cela 
s'effectue au moyen de la classe CastorMarshaller localisee dans le package 
org. springf ramework.oxm. castor. 

Comme Findique le code suivant, le mapping se parametre dans le fichier de configuration 
XML de cette classe (©) par Fintermediaire de la propriete mappingLocation (Q) : 

<bean id="castorMarshaller"<— Q 

cl as s=" org. spr i ngf ramework.oxm. castor. CastorMarshal ler"> 
<property name="mappi ngLocation"<— Q 

val ue="cl ass path : /tudu/web/ws/bean/mapping.xml "/> 

</bean> 
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Le fichier de mapping suit la structure specifiee par Foutil Castor XML. Le code suivant illustre 
la mise en ceuvre d'un fichier de ce type afin de configurer les classes TodosLi st : 

<?xml version-"!. 0"?> 
<!D0CTYPE mapping PUBLIC 

"-//EXOLAB/Castor Mapping DTD Version 1.0//EN" 

"http://castor.org/mapping.dtd"> 
<mapping> 

(...) 

<class name="tudu. domain. model .TodoList"> 
<map-to xml="TodoList" 

ns - uri-"http:/ /sou reef orge.net/tudu/ schema s"/> 

<field name="l i stld" type="java.lang.String"> 
<bind-xml name="ListId" node="el ement"/> 
</field> 

<field name="name" type="java.lang.String"> 
<bind-xml name="Name" node="el ement"/> 
</field> 

<field name="rssAllowed" type="java.lang.Boolean"> 

<bind-xml name="RssAllowed" node="el ement"/> 
</field> 

<field name="l astUpdate" type=" java . uti 1 .Date"> 

<bind-xml name=" LastUpdate" node="el ement"/> 
</field> 
</cl ass> 

(...) 

</mapping> 

L'instance de la classe CastorMarshaller configuree peut ensuite etre injectee dans un 
endpoint afin de lui mettre automatiquement a disposition les donnees contenues dans le 
message XML en entree sous forme d'objets et de construire en retour les donnees XML pour 
la reponse. 

Spring WS propose Fespace de nommage oxm afin de faciliter la configuration des entites de 
mapping, mais seuls les outils JAXB 1 et 2, XmlBeans et JiBX sont configurables par ce biais. 

Le code suivant decrit la configuration (Q) et Futilisation (Q) de l'espace de nommage afin 
de configurer un marshaller JAXB 2 : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. springframework.org/schema/beans" 
xml ns :xsi="http: //www. w3 .org/2001 /XMLSchema-i nstance" 
xml ns :oxm="http: //www.springf ramework. org/schema/oxm"<— Q 
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xsi : schema Location-" http://www.spri ngframework.org/schema/beans 
http: //www.springf ramework. org/schema/ 

beans /spring -beans -2. 5. xsd 
http: //www.springf ramework. org/schema /oxm<— Q 
http: //www. spri ngframework.org/schema/ 

oxm/spring-oxm-1.5.xsd"> 

<oxm:jaxb2 -marshal 1 er id=" jaxb2Marshal 1 er"<— Q 
context Pa th="tudu.ws .bean"/> 

</beans> 

Appels des services 

Spring WS offre une API cliente permettant d'appeler des services Web tout en fournissant 
deux approches au niveau du traitement des donnees envoyees et recues. L'utilisation de Tune 
ou de F autre depend de la maniere dont le developpeur souhaite les manipuler. 

Dans les deux cas, l'appel des services Web se fonde sur la classe WebServiceTemplate, un 
template Spring dedie. Cette entite integre de maniere transparente differentes possibilites de 
transport des messages grace a la propriete messageSender de type MessageSender. Nous abor- 
dons plus en detail cette propriete a la section « Gestion des transports ». 

La classe WebServiceTemplate comporte en outre une propriete messageFactory de type 
WebServiceMessageFactory, qui decrit la maniere de creer les messages mis en ceuvre dans la 
communication avec les services Web. 

Le code suivant met en ceuvre de Fapproche fondee sur la technologie SAAJ (0) et sa speci- 
fication au sein du template avec Fattribut messageFactory (Q) : 

<bean id="messageFactory" class-"org.springframework.ws<— Q 
.soap. saaj . SaajSoapMes sage Facto ry"/> 

<bean id="webServiceTemplate" 

class="org.springf ramework. ws .cl ient .core. WebServiceTempl ate" > 

<property name="messageFactory" ref="messageFactory"/><— Q 

(...) 
</bean> 

Utilisation des messages 

Spring WS propose differentes approches pour realiser des appels de services Web et gerer les 
donnees mises en ceuvre. 

Une premiere approche, de plus bas niveau, permet de travailler directement au niveau des 
messages XML en recourant aux interfaces Source et Result. Ladresse du service a acceder 
peut etre specifiee globalement pour le template ou specifiquement au moment de l'appel. 
Comme Findique le code suivant, la methode sendSourceAndReceiveToResult (0) peut etre 
utilisee pour realiser l'appel au service Web et recevoir la reponse : 



String xmlMessage = (...); 
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StreamSource source 
StreamResul t result 



new StreamSource(new StringReader(message) ) ; 
new StreamResult(System.out) ; 



//Envoi et reception de message avec 1'adresse par defaut 
webServi ceTempl ate .sendSourceAndRecei veTo Result (<— © 

source, result); 

//Envoi et reception de message avec une adresse specifique 
String adresseSpecifique = (...); 

webServi ceTempl ate .sendSourceAndRecei veTo Result (<— © 

adresseSpecifique, source, result); 

Differentes entites permettent d'ajouter des traitements dans la chaine d'envoi de la requete et 
de reception de la reponse. Ce mecanisme permet de modifier le contenu du message au 
niveau de la chaine de traitement. II s'appuie sur la classe WebServi ceMessage, qui permet 
d'acceder au contenu du message independamment de la technologie XML employee. 
Le code suivant decrit le contenu de l'interface WebServi ceMessageCal 1 back fournissant une 
reference au message courant : 

public interface WebServi ceMessageCal 1 back { 

void doWithMessage(WebServiceMessage message) 

throws IOException, TransformerException; 

} 

Le code suivant montre que cette interface peut etre utilisee, par exemple, pour positionner 
Fen-tete SOAPActi on (©) pour un appel d'un service Web : 



String xmlMessage = 
| StreamSource source 
StreamResult result 



(...); 

- new StreamSource(new StringReader(message) ) ; 
= new StreamResult(System.out) ; 



webServi ceTempl ate .sendSourceAndRecei veTo Result ( 

source, new WebServi ceMessageCal 1 back( ) { 
public void doWithMessage(WebServiceMessage message) { 
( (SoapMess age )mes sage) . setSoapActi on(<— © 

"http://tempuri .org/Action") ; 

} 

}, result); 

D'autres methodes de la classe WebServi ceTempl ate integrent un mecanisme de conversion 
fonde sur les interfaces SourceExtractor et WebServi ceMessageExtractor. Elles utilisent 
respectivement des objets de types Source et WebServi ceMessage arm de creer des objets inde- 
pendants de la technologie XML. 

Le code suivant decrit la mise en ceuvre de l'interface SourceExtractor au sein de la methode 
sendAndReceive du template : 



String xmlMessage = 
StreamSource source 



(...); 

= new StreamSource(new StringReader(message) ) ; 



Object result = webServiceTemplate.sendSourceAndReceive ( 
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source, new SourceExtractor () { 
public Object extractData(Source source) { 
(...) 

} 

} 

Mapping des donnees 

Le template WebServiceTemplate offre la possibilite d'integrer les mecanismes de mapping 
XML/objet decrits a la section « Mapping des donnees » directement au niveau des appels de 
services Web. Cela permet de passer un objet directement en parametre independamment de la 
technologie XML et de recevoir les donnees de la reponse dans un objet du meme type. 

Le mecanisme de mapping integre au template reutilise les mecanismes precedemment decrits 
et associes aux interfaces Marshal ler et Unmarshal 1 er. Les implementations utilisees de ces 
deux interfaces peuvent etre injectees dans ce template a l'aide de ses proprietes marshal 1 er et 
unmarshal 1 er. 

Le code suivant illustre la configuration de ce mecanisme (Q) au moyen de la technologie 
Castor XML (©) : 

<bean id="webServiceTemplate" 

cl ass="org.springf ramework.ws .cl ient .core. WebServiceTempl ate"> 
<property name="marshal 1 er" ref="castorMarshal ler"/><— Q 
<property name="unmarshal 1 er" ref="castorMarshal 1 er"/><— Q 

</bean> 

<bean id="castorMarshaller"<— Q 

cl ass="org.springf ramework.oxm. castor. Cas to rMarshal ler"> 
(...) 

</bean> 

Une fois le template configure, les methodes marshal SendAndReceive peuvent etre utilisees. 
Elles possedent differentes variantes, dont certaines acceptent un parametre de type 
WebServi ceMessageCal 1 back afin de modifier la requete une fois le contenu ajoute. 

Le code suivant illustre la mise en ceuvre de la methode marshal SendAndReceive : 
j Object i nput = (...); 

| Object result = webServiceTemplate.marshalSendAndReceive(input); 

Gestion des transports 

Outre le protocole HTTP, Spring WS propose un cadre generique permettant d'utiliser simple- 
ment d'autres technologies de ttansport. Ce cadre permet en outre de reutiliser tous les meca- 
nismes decrits precedemment. Aucun changement n'est done necessaire au niveau de 
l'aiguillage et des endpoints, et seules les entites relatives a l'acces doivent etre adaptees. 
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Le framework supporte les differentes technologies de transport decrites au tableau 13-4. 



Tableau 13-4. Technologies de transport supportees par Spring WS 


Transport 


Description 


HTTP 


Protocole par defaut pour I'utilisation des services Web. Son utilisation dans Spring WS s'appuie sur la ser- 
vlet MessageDispatcherServlet. 


JIVIO 
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technologie peut etre utilisee afin d'appeler des services Web de maniere asynchrone. Spring WS propose 
des observateurs JMS par I'intermediaire des classes WebServi ceMessageLi stener et WebServi ceMes- 
sageDrivenBean, cette derniere correspondant a un EJB Message Driven. 


POP et IMAP 


Les protocoles relatifs a I'echange d'e-mails peuvent etre utilises afin d'interagir avec un service Web pour 
recuperer les requetes et les envoyer de fagon asynchrone. Spring WS fournit la classe MailMessageRe- 
ceiver afin de les mettre en ceuvre. 


HTTP embarque 


Depuis sa version 6, Java integre en standard un serveur Web. Ce dernier est particulierement leger en com- 
paraison des serveurs Web classiques et peut etre mis en ceuvre dans une application autonome. Spring 
WS fournit les classes WsdlDefinitionHttpHandler et WebServiceMessageReceiverHttpHandler a 
cet effet. 

I 



Bien qu'un des objectifs de Spring WS soit Findependance vis-a-vis du transport, il est a noter 
qu'il est parfois necessaire d'acceder a des proprietes au niveau de la couche de transport. Le 
framework propose pour cela la classe TransportContext, qui permet de recuperer la 
connexion utilisee. 

Comme cette classe est stockee dans un ThreadLocal, elle peut etre utilisee a n'importe quel 
moment dans 1' application au sein d'une requete. 

Le code suivant decrit I'utilisation de cette classe afin de recuperer Fadresse IP du client du 
service Web : 

TransportContext context 

= TransportContextHolder.getTransportContext( ) ; 
HttpServl etConnection connection 

= (HttpServletConnection )context.getConnection( ) ; 
HttpServl etRequest request = connection .getHttpServl etRequest( ) ; 
String ipAddress = request. getRemoteAddr( ) ; 

Spring WS permet de configurer en tant que Beans des entites de reception de messages JMS. 
Ces entites sont appelees conteneurs JMS. Une entite de ce type, par exemple la classe 
DefaultMessageListenerContainer, s'appuie sur les entites JMS ConnectionFactory et 
Destination pour obtenir des connexions au middleware et preciser la destination a utiliser. 

Lobservateur JMS utilise des entites de types MessageFactory pour la creation des messages 
et MessageDispatcher pour leur traitement. Les classes SaajSoapMessageFactory et 
SoapMessageDispatcher peuvent etre utilisees a cet effet. 

Le code suivant decrit la mise en ceuvre de la technologie de transport JMS pour la configuration 
du conteneur JMS (Q) de Spring et de l'observateur JMS (©) fourni par Spring WS : 

<bean id="connectionFactory" 

cl ass=" org. apache. act ivemq. Act iveMQConnect ion Factory "> 
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<property name="brokerllRL" 

val ue="vm: //I ocal host?broker.persistent=fal se"/> 

</bean> 

<bean cl ass-" org. springf ramework. jms<— Q 

. 1 i stener. Def aul tMessageLi stenerContainer"> 
<property name=" connect i on Factory" ref=" connect ion Factory"/) 
<property name="destinationName" val ue="TuduQueue"/> 
<property name="messagel_istener" ref="messageLi stener"> 

</bean> 



<bean id="messageListener" class="org.springframework.ws<— Q 

. transport . jms . WebServi ceMes sage Li stener "> 
<property name="messageFactory" ref="messageFactory"/> 
<property name="messageReceiver" ref="messageDi spatcher"/> 

</bean> 

<bean id="messageFactory" cl ass="org. springf ramework. ws 

. soap. saaj .SaajSoapMessageFactory"/> 

<bean id-"messageDispatcher" cl ass="org. springf ramework. ws 
.soap.server.SoapMessageDispatcher"> 
<property name="endpointMappings" ref="endpointMappings"/> 
</bean> 



<bean id="endpointMappings" cl ass=" org. spr i ngf ramework. ws. server 
.endpoint. mapping. Pay loadRootQNameEndpointMapping"> 

(...) 

</bean> 

Pour mettre en ceuvre la technologie relative aux e-mails, la classe MailMessageReceiver de 
Spring WS doit etre utilisee. Elle permet notamment de preciser les informations relatives aux 
serveurs POP ou IMAP et SMTP. Comme precedemment, la classe se fonde sur des entites de 
type MessageFactory et MessageDi spatcher. Les merries implementations peuvent done etre 
utilisees a ce niveau. 

Le code suivant illustre le parametrage de la classe Mai 1 MessageRecei ver concemant l'adresse 
de messagerie (Q) et les proprietes IMAP (Q) et SMTP (©) : 

<bean id="messagingRecei ver" cl ass-" org. springf ramework. ws*» 

.transport .ma i 1 .Mai 1 MessageRecei ver "> 
<property name="messageFactory" ref="messageFactory"/> 
<property name="f rom"<— Q 

value="Mon Adresse <ws@serveur.com>"/> 
<property name="storeUri "<— Q 

val ue=" i map:/ /server : s04p@i map. se rveur.com/ INBOX "/> 
<property name="transportUri "<— Q 

val ue="smtp: //smtp. serveur . com"/> 
<property name="messageRecei ver" ref="messageDi spatcher"/> 
<property name="moni tori ngStrategy"> 
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<bean cl ass="org. spri ngf ramework.ws . transport<— Q 

.mail .monitor. Pol 1 ingMonitoringStrategy"> 
<property name="pol 1 inglnterval " val ue="30000"/> 
</bean> 
</property> 
</bean> 

<bean id="messageFactory" class="org.springframework*» 

.ws .soap. saaj . SaajSoapMes sage Factory"/) 

<bean id="messageDispatcher" cl a ss=" org. spri ngf ramework.ws 
.soap. server . SoapMessageDi spatcher"> 
<property name="endpointMappings" ref="endpointMappings"/> 
</bean> 

<bean id="endpointMappings" cl a ss=" org. spri ngf ramework.ws .server 
. endpoint. mapping. PayloadRootQNameEndpointMapping"> 

(...) 

</bean> 

Nous ne detaillons pas ici la configuration de la derniere approche, celle-ci utilisant le serveur 
Web integre a Java et se fondant sur des mecanismes similaires. 



En resume 

Le framework Spring WS offre une approche interessante afin de mettre en ceuvre des services 
Web simplement en recourant aux mecanismes de Spring. Le framework a fait le choix d'une 
approche par contrats de services afin de contourner les principaux problemes lies aux services 
Web. 

Differentes strategies sont proposees pour mettre en ceuvre les traitements des endpoints en se 
calquant sur le modele de programmation de Spring MVC. Une chaine de traitement claire- 
ment identifiee et extensible est integree a cet effet au framework. Dans ce contexte, une 
approche particulierement flexible et fondee sur les annotations est fournie. 

Des mecanismes utilisant une approche par template sont proposes afin de realiser Fappel de 
services Web de maniere simple. Ces mecanismes incluent l'utilisation d'interfaces pour 
exploiter les messages echanges. 

Spring WS integre des abstractions de haut niveau afin d'utiliser les outils de mapping XML/ 
objet en son sein, que ce soit pour la mise en ceuvre des services ou pour leurs appels. Les 
entites d'appel ou de traitement de services Web deviennent des lors completement indepen- 
dantes des technologies XML sous-jacentes. 

Differents protocoles de transport sont supportes en standard par Spring WS, la technologie 
par defaut etant HTTP. Le choix du transport n'impacte en aucune maniere les entites deve- 
loppees et peut etre modifie simplement par la configuration aussi bien au niveau client que 
serveur. 
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La mise en ceuvre de la securite proposee en standard par l'outil s'appuie sur les technologies 
XWSS de Sun et WSS4J d' Apache. 

Mise en oeuvre de Spring WS dans Tudu Lists 



Les principaux concepts et composants de Spring WS ayant ete introduits, nous pouvons 
passer a leur mise en pratique dans notre etude de cas. 

Configuration des contextes 

A l'instar de Spring MVC, la configuration de Spring WS se realise dans le fichier web.xml de 
1' application Web a deux niveaux. 

Le premier niveau est le contexte applicatif de l'application Web et est configure de maniere 
classique par 1' intermediate de l'observateur ContextLoaderListener de Spring : 

<context-param> 

<param-name>contextConf i gl_ocation</param-name> 

<param-val ue>/WEB- INF/appl i cationContext*.xml </param-val ue> 

</context-param> 

<1 i stener> 

<1 1 stener-cl ass> 

org. springframework. web. context. Context Loader Listener 

</l i stener-cl ass> 
</l i stener> 

Les Beans relatifs aux services metier, aux composants d'acces aux donnees et aux instances 
qui leur sont relatives doivent etre configures a ce niveau. 

Le contexte relatif a la servlet de Spring WS doit ensuite etre mis en ceuvre. La configuration 
de la servlet MessageDispatcherServlet permet de realiser cela de maniere implicite. Cette 
derniere classe doit etre definie dans le fichier web.xml, comme le montre le code suivant : 

<servl et> 

<servl et-name>spring-ws</servl et-name> 
<servlet-class> 



</servl et-cl ass> 
</servl et> 

<servlet-mapping> 

<servl et-name>spring-ws</servl et-name> 
<url -pattern>/*</url -pattern> 

</servlet-mapping> 



org. springf ramework.ws .transport 

. http.MessageDi spatcherServl et 
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Par defaut, le contexte applicatif associe a la servlet ci-dessus doit etre configure dans un 
fichier spring-ws-servlet.xml localise dans le repertoire WEB-INF. Ce fichier contient tous 
les Beans relatifs a la mise en ceuvre de Spring WS. 

Definition des contrats des services 

Une fois le framework Spring WS configure, les contrats des services ainsi que les structures 
des donnees echangees peuvent etre definis. 

Pour cette etude de cas, nous avons realise une application simplifiee permettant les operations 
suivantes : 

• recuperation de la liste des todolists pour un utilisateur ; 

• recuperation de la liste des todos pour un identifiant de todos. 

II est a noter que les donnees contenues dans ces entites ont ete reduites au strict minimum. 

Afin de pouvoir exploiter ces donnees par l'intermediaire de services Web, leur structure ainsi 
que celle des messages echanges doivent etre definies avec XML Schema. Le fichier corres- 
pondant se nomme dans notre cas tudu.xsd et se situe dans le repertoire WEB-INF. 

Ce fichier contient tout d'abord les structures relatives aux todos (Q) et aux todolists (0) : 

<xs : schema xml ns :xs="http: //www. w3.org/2001/XMLSchema" 

xml ns : tudu="http: //sou reef orge.net/tudu/schemas" 
el ementFormDef aul t="qual if ied" 

target Namespace="http: //sourcef orge.net/tudu/schemas"> 

<xs : compl exType name="Todol_i stType"><— Q 
<xs : sequence> 

<xs:element name="ListId" type="xs:string"/> 

<xs:element name="Name" type="xs:string"/> 

<xs:element name="RssAl 1 owed" type="xs:boolean"/> 

<xs:element name="LastUpdate" type="xs:date"/> 
</xs :sequence> 
</xs: compl exType> 

<xs : compl exType name="TodoType"><— Q 
<xs : sequence> 

<xs:element name="TodoId" type="xs:string"/> 

<xs:element name="Description" type="xs : stri ng"/> 

<xs:element name="Priority" type="xs:int"/> 

<xs:element name="Compl eted" type="xs:boolean"/> 

<xs:element name="CreationDate" type="xs :date"/> 
</xs : sequence) 
</xs:complexType> 



(...) 

</xs : schema> 
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En s'appuyant sur les definitions precedentes, il definit egalement les messages echanges 
permettant de recuperer des listes de todolists (0) et de todos (Qi) : 

<xs : schema xml ns :xs="http: //www. w3.org/2001/XMLSchema" 

xml ns : tudu="http: //sourcef orge.net/tudu/schemas" 
elementFormDefault="qual ified" 

target Namespace="http: //sourcef orge.net/tudu/schemas"> 



<xs :el ement name="GetTodol_i stsRequest"><— Q 
<xs:complexType> 
<xs:sequence> 

<xs:element name="UserId" type="xs:string"/> 
</xs : sequence> 
</xs:complexType> 
</xs:element> 

<xs :el ement name="GetTodol_i stsResponse"><— Q 
<xs:complexType> 
<xs:all> 



</xs:all> 
</xs : compl exType> 
</xs:element> 

<xs : el ement name="GetTodosRequest"><— Q 
<xs: compl exType> 
<xs:sequence> 

<xs:element name="ListId" type="xs:string"/> 
</xs : sequence> 
</xs : compl exType> 
</xs:element> 

<xs : el ement name="GetTodosResponse"><— Q 
<xs: compl exType> 
<xs:all> 

<xs:element name="Todos" type-"tudu:TodoType"/> 
</xs:all> 
</xs : compl exType> 
</xs:element> 

</xs :schema> 

Une fois, le fichier defini, ce dernier doit etre configure dans Spring par 1' intermediate de la 
classe SimpleXsdSchema. En s'appuyant sur cette entite, Futilisation de Fentite 
DefaultWsdl UDefinition permet a Spring WS de deduire le conttat du service au format 
XML a Faide de la technologie WSDL. 



(...) 



<xs:element name="Todol_i st" 

type="tudu:Todol_istType"/> 
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La configuration des aspects relatifs a la structure des messages echanges et au contrat du 
service se realise dans le fichier de configuration de Spring de la maniere suivante : 

<bean id="tudu" cl ass="org.springf ramework.ws 

.wsdl .wsdlll.DefaultWsdlllDefinition") 
<property name="schema" ref="schema" /> 
<property name="portTypeName" val ue="Tudu" /> 
<property name="locationUri" 

val ue="http: //local host :9080/tudu-ws/tudu/" /> 
<property name="targetNamespace" 

val ue="http:/ /sou reef orge.net/tudu/defi nit ions" /> 

</bean> 

<bean id="schema" 

cl ass-"org.springf ramework.xml .xsd.SimpleXsdSchema"> 
<property name="xsd" val ue="/WEB- INF/tudu.xsd" /> 
</bean> 

Le contenu WSDL correspondant est alors disponible a l'adresse http://<serveur>:<port>/ 
<nom-application>/tudu. wsdl. 



Mapping des messages echanges 

Afin de simplifier les traitements contenus dans les endpoints, nous allons mettre en applica- 
tion une approche de mapping des donnees des messages dans des objets. Nous utiliserons 
pour cela l'outil Castor XML, dont la mise en ceuvre repose sur un fichier de correspondance 
au format XML. 

Ce fichier, nomme mapping.xml dans notre contexte, suit la structure definie par Castor et 
specifie la maniere dont les donnees XML relatives aux messages et donnees sont mises en 
relation avec les classes Java definies dans 1' application. Afin de decorreler les objets metier 
des donnees echangees, des classes simplifiees, appelees RemoteTodoList et RemoteTodo, ont 
ete definies pour les todolists et les todos. 

Le contenu du fichier de mapping est le suivant (la partie relative aux todos a ete omise car elle 
est similaire a celle des todolists) : 

<?xml version="1.0"?> 
<!D0CTYPE mapping PUBLIC 

"-//EXOLAB/Castor Mapping DTD Version 1.0//EN" 

"http://castor.org/mapping.dtd"> 
<mapping> 

<class name="tudu.web.ws . bean. GetTodo Lists Request") 
<map-to xml="GetTodoListsRequest" 

ns -uri-"http:/ /sou reef orge. net /tudu/schemas"/> 



<field name="userld" type="java.lang.String"> 
<bind-xml name="UserId" node="el ement"/> 
</field> 
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</cl ass> 

<cl ass name-" tudu. web. ws .bean .GetTodoLi stsResponse"> 
<map-to xml="GetTodoLi stsResponse" 

ns -uri-"http://sourceforge. net /tudu/s enemas "/> 

<field name="todoLi sts" 

type=" tudu. web. ws .bean . RemoteTodoList" 
collection-"set" > 
<bind-xml name="TodoLi st" /> 
</field> 
</cl ass> 

<cl ass name=" tudu. web. ws .bean. RemoteTodoList "> 
<map-to xml="TodoLi st" 

ns-un'="http: //sourcef orge.net /tudu/schemas"/> 

<field name="l istld" type="java.lang.String"> 
<bind-xml name=" Li stld" node="el ement"/> 
</field> 

<field name="name" type="java.lang.String"> 
<bind-xml name="Name" node="el ement"/> 
</field> 

<field name="rssAllowed" type="java.lang.Boolean"> 

<bind-xml name="RssAllowed" node="el ement"/> 
</field> 

<field name="l astUpdate" type-" java . uti 1 . Date"> 
<bind-xml name=" LastUpdate" node="el ement"/> 
</field> 
</cl ass> 



Une fois le contenu de ce fichier defini, l'entite de Spring WS dediee a Castor doit etre confl- 
guree. Cette classe, nommee CastorMarshaller, reference le fichier precedent par Finterme- 
diaire de sa methode mappingLocation : 

<bean id="castorMarshaller" 

cl ass-"org.springf ramework.oxm. castor. Cas to rMars ha 1 ler" > 
<property name="mappi ng Location" 



(...) 



</mapping> 



val ue="cl asspath: /tudu/web/ws/bean/mapping.xml " /> 



</bean> 
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Implementation des endpolnts 

Une fois ce travail preparatif realise, les differents endpoints peuvent etre mis en ceuvre. Pour 
plus de clarte, nous avons retenu l'approche fondee sur les annotations PayloadRoot et le 
mapping XML/objet. 

Les classes relatives aux endpoints doivent posseder Fannotation Endpoint ainsi que des 
methodes annotees avec PayloadRoot. Ces dernieres pourront prendre ainsi pail aux fake- 
ments des requetes. 

La selection de la methode se fonde sur Fespace de nommage de la requete ainsi que sur sa 
balise racine. Dans notre cas, Fespace de nommage est celui defini dans le fichier XML 
Schema definissant la structure des donnees, a savoir http://sourceforge.net/tudu/schemas. 
Les balises racines dependent des requetes, et ce sont elles qui vont permettre Faiguillage. 

Dans la classe TodoListsEndpoint adressant les requetes relatives aux todolists, la methode 
getTodoLists retourne les todolists pour un identifiant d'utilisateur. Elle s'appuie sur le 
service injecte pour recuperer les donnees puis les convertit et les positionne au niveau de la 
reponse. La methode getTodoLists (Q) est appelee lorsque la requete contient la balise 
GetTodoListsRequest (Q) comme racine de message : 

©Endpoint 

public class TodoListsEndpoint { 

private TodoLi stsManager todoListsManager; 

@PayloadRoot(local Part = "GetTodoListsRequest" ,<— © 

namespace = "http://sourceforge.net/tudu/schemas") 
public GetTodoListsResponse getTodoLists(<— Q 

GetTodoListsRequest request) { 
String userld = request . getUserId( ) ; 

SeKTodoLi st> todoLists 

= todoListsManager. f indByLogin(userld) ; 

Set<RemoteTodoLi st> remoteTodoLists 

= RemoteTodoLi stUti 1 s . convert(todoLi sts ) ; 

GetTodoListsResponse response = new GetTodoLi stsResponse( ) ; 
response. setTodoLi sts (remoteTodoLists) ; 
return response; 

) 



} 

(... 

) 



Le mapping des objets relatifs a la requete et a la reponse se fait automatiquement en fonction 
du marshaller configure au niveau des adaptateurs de traitement. 
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Les instances des endpoints doivent ensuite etre configurees en tant que Beans dans Spring 
afin de pouvoir etre appelees. Les services metier correspondant doivent etre injectes dans les 
endpoints a ce niveau. 

Dans le code suivant, nous specifions differents adaptateurs afin d'utiliser les annotations pour 
aiguiller les traitements (Q) et le mapping des donnees XML (Qi) : 

<bean cl ass="org.springf ramework.ws. server. endpoint<— © 

.mapping. Pay load Root Annot at ionMet hod EndpointMapping"/> 

<bean cl as s=" org. sp r i ngf ramework.ws . server. endpoint<— © 

.adapter .MessageMethodEndpointAdapter"/> 

<bean cl as s=" org. s pri ngf ramework. ws. server. endpoint<— © 

. adapter .Generi cMarshal 1 ingMethodEndpoint Adapter "> 
Constructor- a rg ref="castorMarshal 1 er"/> 
</bean> 

(...) 



Implementation de clients 

Maintenant que tous les elements ont ete implemented et configures au niveau du serveur, une 
entite cliente d'appel distant peut etre developpee. Les traitements de cette derniere se fondent 
sur le template WebServiceTempl ate afin de realiser les appels de maniere simple. 

Cette classe offre la possibilite d'utiliser le mapping XML/objet afin de manipuler sous forme 
d'objets et independamment de XML les donnees echangees. Les configurations realisees 
pour la partie serveur peuvent etre reutilisees a ce niveau. 

Pour realiser l'appel avec le mapping, la methode marshalSendAndReceive du template peut 
etre utilisee. Dans notre cas, l'appel distant de la recuperation des todolists necessite un objet 
de type GetTodoListsRequest comme parametre (©), un objet de type GetTodoListsResponse 
etant retourne (Q) par l'appel de la methode precedente (©) : 

GetTodoListsRequest request = new GetTodoLi stsRequest( ) ;<— Q 
request . setUser Id ( "user Id" ) ; 

GetTodoListsResponse response<— Q 

= (GetTodoLi stsResponse)webServi ceTempl ate 

.marshal SendAndRecei ve( request ) ;<— © 

Set<RemoteTodoList> todoLists = response. getTodoLists( ) ; 

La configuration de notre entite cliente et des entites relatives se realise dans un fichier de 
configuration Spring dedie : 

<bean id="messageFactory" cl ass="org. springf ramework.ws 

. soap. saaj .SaajSoapMessageFactory"/> 

<bean id="webServiceTemplate" class="org. spring-framework^ 



Technologies d'integration 

Partie IV 



.ws.cl ient .core. WebServiceTempl ate" > 
<property name="messageFactory " ref="messageFactory"/> 
<property name="defaultUri " 

value="http: //local host :9080/tudu-ws/"/> 
<property name="marshal 1 er" ref="castorMarshal 1 er"/> 
<property name="unmarshal 1 er" ref="castorMarshal 1 er"/> 
</bean> 

<bean id="castorMarshaller" 

cl ass-" org. spr i ngf ramework.oxm. castor. CastorMars ha 1 1 er"> 
<property name="mapping Location" 

val ue="cl asspath: /tudu/web/ws/bean/mapping.xml " /> 

</bean> 

<bean id="webServiceClient" 

cl ass="tudu.web.ws .cl ient .WebServiceCl ient"> 
<property name="webServi ceTempl ate" ref="webServiceTempl ate"/> 
</bean> 



En resume 

La mise en ceuvre de Spring WS dans F etude de cas illustre avec quelle facilite et quelle flexi- 
bilite ce framework perniet d'exposer des services existants par Fintermediaire de services 
Web. La premiere etape a consiste a definir la structure des donnees manipulees, apres quoi le 
framework s'est charge de deduire la structure XML des contrats des services exposes. 

Suivant le meme modele de programmation que Spring MVC, Spring WS tire parti des anno- 
tations tout en permettant Futilisation du mapping de donnees XML/objet. Le code des 
endpoints est des lors tres concis et completement independant des technologies XML. 

Au niveau du client, Spring WS offre la possibility de realiser des appels simplement tout en 
supportant certains mecanismes mis en ceuvre dans la partie serveur, tels que le mapping 
XML/objet. 



Conclusion 

Ce chapitre a montre comment mettre en ceuvre et appeler des services Web en se fondant sur 
le framework Spring WS, Foutil du portfolio de Spring dedie a cette technologie. Ce 
framework met en ceuvre une approche dirigee par les contrats afin d'adresser au mieux la 
coexistence des paradigmes XML et objet, dont il a su simplifier Futilisation grace a Finjection de 
dependances et a un modele de programmation similaire a celui de Spring MVC. 

Lobjectif de Spring WS est de rendre les plus independantes possibles des technologies XML 
les entites developpees, mais des approches plus liees a XML ne sont pas moins toujours utili- 
sables. 

Puisque la chaine de traitement est completement flexible et extensible, les entites centrales, 
les endpoints, peuvent etre configurees avec des annotations et integrer le mapping XML/ 
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objet. Cette approche permet de definir plusieurs methodes de traitement par endpoint et de 
travailler directement sur des objets de donnees. 

Au niveau de la partie cliente, Spring WS met en ceuvre les merries mecanismes en s'appuyant 
sur un template permettant notamment d'utiliser le mapping objet/XML. 

Nous avons volontairement passe sous silence F aspect securite, mais il est a noter que Spring 
WS peut etre securise comme n'importe quelle application Web avec Spring Security. Le 
framework fournit egalement un interessant support de WS-Security. 
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Sur Internet, mais aussi au cceur meme d'une entreprise, le risque de compromission de 
donnees sensibles peut conduire a des catastrophes en termes economiques ou legaux. La 
securite est done un aspect important du developpement d'une application. Sujet complexe, 
s'il en est, elle ne doit pas etre traitee a la legere. Pour ces raisons, ce chapitre commence par 
rappeler les besoins couramment exprimes en matiere de securite, ainsi que les concepts cles 
generalement utilises dans ce domaine. 

En Java, nous disposons de JAAS (Java Authentication and Authorization Service) et de la 
specification Java EE pour nous aider dans cette tache. II s'agit de standards largement utili- 
ses, qu'il est important de connaitre, puisqu'un grand nombre de solutions s'appuient sur eux. 
Nous verrons les limitations de ces deux specifications et les raisons pour lesquelles elles ne 
sont pas suffisantes pour developper des applications d' entreprise un tant soit peu complexes. 

Spring Security est un projet du portfolio Spring qui propose une solution de securite 
complete integree aux systemes utilisant Spring. Tres largement utilisee au sein de la commu- 
naute Spring, elle peut de facto etre consideree comme un standard. 

Dans ce chapitre, nous commencons par exposer les besoins de securite d'une application 
Web d' entreprise puis montrons comment Spring Security peut y repondre. 

La securite dans les applications Web 

Cette section rappelle les besoins habituellement exprimes pour la securisation d'une applica- 
tion, ainsi que les concepts utilises pour repondre a ces besoins. Nous pourrons de la sorte 
mieux comprendre les specificites fonctionnelles et techniques induites par la securite. 

Nous nous interesserons en particulier aux applications d'entreprise, et plus specifiquement 
aux applications Web fondees sur Java EE, qui sont la cible meme de cet ouvrage. 
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Les besoins 

La grande majorite des applications ont les memes besoins en matiere de securite. C'est 
d'ailleurs pour cette raison que la creation d'un mecanisme specifique de gestion de la secu- 
rite ne se justifie pas toujours et que l'utilisation d'un framework preexistant est largement 
preferable. 

Gestion des utilisateurs 

Les utilisateurs, leur mot de passe et leurs droits doivent etre geres dans un systeme specialise. 
Dans les entreprises, il est courant que ce systeme soit un referentiel centralise, tel un annuaire 
LDAP. II s'agit d'une base de donnees optimisee pour les requetes en lecture et possedant une 
stmcture arborescente permettant de stacker des hierarchies. Nous rencontrons aussi des 
systemes plus simples, reposant sur des bases de donnees relationnelles. 

Ces systemes ont, de preference, les caracteristiques suivantes : 

• Gestion d'attributs lies a Futilisateur (nom, numero de telephone, etc.). 

• Verification du mot de passe. II est preferable qu'un systeme externe gere les mots de passe, 
plutot que chaque application utilisatrice. 

• Gestion des droits des utilisateurs. 

• Gestion des groupes d' utilisateurs, qui facilite la gestion des droits. 

II va de soi que les entreprises ne fournissent pas toujours un systeme de gestion des droits 
aussi complet. Les developpeurs doivent regulierement faire face a des situations degradees, 
dans lesquelles certains de ces besoins ne peuvent etre pris en compte ou doivent etre developpes 
specifiquement. 

Securisation des URL 

La securisation la plus simple a mettre en place est celle des requetes HTTP. Nous decidons de 
ne permettre qu'a un certain type d'utilisateur d'acceder a une URL donnee. Dans Tudu Lists, 
par exemple, les URL se terminant par /secure/** sont reservees aux utilisateurs authentifies 
et possedant le role ROLEJJSER. 

Ce type de securisation peut etre mis en place aux niveaux suivants : 

• Reseau, avec utilisation d'un repartiteur de charge (de type Alteon). 

• Serveur Web, avec, par exemple, utilisation de la securite dans Apache. 

• Serveur Java EE, que nous detaillons plus en detail par la suite parce qu'il propose une inte- 
gration beaucoup plus avancee de la securite au sein de 1' application developpee. 

Notons que le principal defaut de cette solution est qu'il est necessaire de disposer d'une 
bonne strategie dans le nommage des URL. Cette politique contraignante est difficilement 
imposable a une application existante. C'est pourquoi elle doit etre mise en place des la 
conception de 1' application. 
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Securisation de la couche de service 

La couche de service n'est normalement pas accessible aux utilisateurs finals de 1' application. 
Cependant, le fait de securiser des Beans Spring presente un double interet : 

• Cela renforce la securite de l'application en empechant un utilisateur malveillant d'y avoir 
acces. Si un service est sensible et ne doit etre utilise que par l'administrateur, mieux vaut 
valider qu'il ne peut etre execute que par des personnes ayant le role adequat. 

• Cela permet l'acces distant a ces objets. II est ainsi possible de permettre a des applications 
externes d'utiliser un service sensible, a condition que leurs utilisateurs soient dument auto- 
rises a y acceder. 

Cette securisation peut se faire au niveau d'une classe ou d'une methode. 
Securisation des objets de domaine 

Plus rarement exprime, ce besoin consiste a securiser certaines instances d'objets metier. 
Dans l'exemple de Tudu Lists, un utilisateur a le droit d'effacer des todos mais ne doit pouvoir 
effacer que les todos qui lui appartiennent. II a done le droit d'executer la methode de suppres- 
sion des donnees (securisation de la couche de service), mais pas sur Fensemble des objets 
metier. 

Ce besoin se fait sentir dans la plupart des applications multiutilisateurs. Dans une boutique 
en ligne, par exemple, un utilisateur n'a le droit de gerer que son panier d' achat. 

Controle du code execute 

Ce besoin, qui se rencontre egalement rarement dans le cadre d'une application Web Java EE, 
consiste a n'autoriser F execution que de code qui a ete valide. L'exemple le plus courant est 
celui des applets. Dans la mesure ou nous executons du code telecharge depuis Internet, nous 
ne pouvons avoir une confiance absolue dans ce programme. 

Dans le cadre d'une application Java EE s'executant sur un serveur d'entreprise, il n'est pas 
utile de prendre en compte ce type de consideration. Si une personne malveillante accede au 
serveur et est capable d'intervenir directement sur du code, elle sera egalement capable d'en 
modifier les regies de securite. Mieux vaut done mettre 1' accent sur la securisation des 
serveurs (et de leurs locaux) et eviter ce type de complexite aux developpeurs d' applications. 



Rappel des principales notions de securite 

La securite s'appuie sur deux notions principales, 1'authentification des utilisateurs et la 
gestion de leurs autorisations, auxquelles se greffe un vocabulaire specialise, que nous allons 
rappeler : 

• Authentification. Verification qu'un utilisateur est bien la personne qu'il pretend etre. Cette 
verification s'effectue generalement a l'aide d'un couple identifiant/mot de passe. 

• Autorisation. Verification qu'un utilisateur authentifie a la permission de realiser une 
action. Un utilisateur possede generalement un ensemble d' autorisations, qui peuvent etre 
gerees par groupes pour plus de facilite. 
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• Les objets Subject et Principal. Specifiques de Java, ces objets se retrouvent dans 
l'ensemble des implementations que nous allons etudier. Un Subject represente un utilisateur 
tel qu'il est vu par l'application en cours. Ce Subject peut posseder plusieurs Principal, 
chacun de ces objets etant une representation de cette personne. Login, numero de Securite 
sociale et adresse e-mail peuvent etre autant de Principal d'un meme Subject. 

• Ressources et permissions. Une ressource represente une entite protegee. II peut s'agir d'un 
fichier, d'une URL ou d'un objet. Une permission correspond au droit d'acceder a cette 
ressource. Pour qu'un utilisateur accede a une URL protegee, il faut que ses autorisations 
lui donnent la permission d'y acceder. 

La securite Java 

Java propose deux API pour gerer la securite : JAAS, pour les projets Java standards (J2SE), 
et une API specifique incluse dans la norme Java EE. 

Nous allons voir que ces API ne repondent que de maniere fragmentaire aux besoins que nous 
avons rappeles precedemment. II est cependant essentiel de les connaitre, car elles composent 
le socle technique standard de Java EE. 

JAAS 

JAAS (Java Authentication and Authorization Service) a ete integre a J2SE 1.4 apres avoir ete 
un package optionnel. 

II s'agit d'une API de bas niveau, permettant en particulier de gerer les privileges du code qui 
s'execute. Peu adaptee a une application Java EE, elle s'adresse a un domaine different : les 
applets et les applications graphiques autonomes fondees sur AWT ou Swing. 

La gestion des utilisateurs en base de donnees ou la creation de formulaires Web de login sont 
des sujets bien eloignes de cette specification, qui n'est pas concue pour cela. Par ailleurs, les 
fonctionnalites qu'elle propose en matiere de gestion des privileges d'execution du code ne 
correspondent pas a une application Web classique. 

Nous ne nous attarderons done pas sur cette specification et nous pencherons plutot sur les 
extensions specifiques a Java EE. 

La specification Java EE 

La specification Java EE inclut plusieurs objets et methodes dedies a la securite. Generale- 
ment simples, ces derniers ont l'avantage d'etre bien integres dans les frameworks existants. 
Struts, par exemple, utilise cette API. 

Si cette specification pose un certain nombre de problemes, que nous allons detailler, elle n'en 
presente pas moins le grand avantage d'etre un standard officiel. 

La specification Servlet permet de definir des regies de securite au niveau du fichier web.xml 
afin de proteger des URL en fonction de leur nom. Elle supporte des methodes d'authentifica- 
tion simples (par formulaire, authentification HTTP basique ou certificat) et fournit une API 
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rudimentaire. Cette API se trouve essentiellement dans deux methodes de Fobjet 
javax.servl et . http.HttpServl et Request : 

• getRemoteUser( ), qui permet d'obtenir le login de l'utilisateur en cours sous forme de 
chaine, a charge pour le developpeur d'appeler la couche de service de son application pour 
retrouver un objet representant l'utilisateur en fonction de ce login. 

• isUserInRole(String role), qui verifie si l'utilisateur en cours possede l'autorisation 
demandee. II est ainsi facile de verifier si l'utilisateur a le role « administrateur » et de lui 
afficher un ecran specifique d' administration. 

Ces deux methodes aussi simples qu'efficaces sont suffisantes pour des applications Web peu 
complexes. 

La specification dans son ensemble souffre toutefois d'un grand nombre d'inconvenients : 

• Elle n'est pas portable d'un serveur d' applications a un autre, chaque serveur Java EE en 
possedant sa propre implementation. Dans le meilleur des cas, migrer vers un nouveau 
serveur peut simplement consister en une configuration specifique de ce module, mais cela 
peut etre nettement plus complique. 

• La gestion des URL dans le fichier web.xml est rudimentaire. II n'est pas possible, par 
exemple, d'utiliser des expressions regulieres (type PERL) pour definir une URL. 

• Les services fournis sont generalement elementaires. II n'y a pas de service d'authentifica- 
tion automatique par cookie, par exemple, ni de systeme pour empecher deux utilisateurs 
d'utiliser le meme login en meme temps, etc. 

• Cette specification reposant sur Fobjet HttpServl etRequest, elle requiert la presence de cet 
objet et n'est done utilisable qu'au plus pres de la couche de presentation. Elle pose en outre 
des problemes en matiere de tests unitaires puisqu'il faut simuler cet objet. 

Utilisation de Spring Security 

Spring Security a pour objectif de proposer un systeme complet de gestion de la securite. 
Cette section presente les avantages foumis par Spring Security par rapport a une solution 
Java EE classique. Nous verrons aussi comment l'installer et le configurer. 

Spring Security est disponible a l'adresse http://static.springframework.org/spring-security/site/ 
index.html. 

Principaux avantages 

Le premier avantage de Spring Security est sa portabilite. Ne dependant pas d'un serveur 
d' applications paiticulier, son utilisation est identique quel que soit le serveur utilise. C'est 
grace a cela que Tudu Lists peut etre utilise sans reconfiguration sur Tomcat, JBoss, Geronimo 
ou WebLogic. 

Cette portabilite est particulierement importante si 1' application developpee doit pouvoir etre 
vendue a un grand nombre de clients possedant des systemes heterogenes. Dans le cadre 
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d'une application developpee en interne, il n'en reste pas moins dommage de se trouver 
bloque sur un serveur d' applications uniquement a cause d'une problematique de securite. 

Le deuxieme avantage de Spring Security est qu'il fournit en standard un nombre de fonction- 
nalites beaucoup plus important qu'un serveur Java EE classique. Parmi les plus simples, et 
qui manquent cruellement dans la specification Java EE, citons Fauthentification automatique 
par cookie pour un nombre donne de jours, ainsi que la verification qu'un utilisateur n'est pas 
deja authentifie avec le login demande. 

Spring Security propose en outre des fonctionnalites avancees, telles que le support de solu- 
tions de solutions de Single Sign-On (une authentification unique pour l'ensemble des appli- 
cations de l'entreprise) ou la securisation des objets de domaine, fournissant ainsi une aide 
considerable au developpement d' applications ay ant des besoins complexes en matiere de 
securite. 

Spring Security propose une excellente integration avec les applications Web et les Beans 
Spring. Concemant les applications Web, il propose des filtres de servlets bien plus fins que 
ceux proposes par la norme Java EE. Pour les Beans Spring, il permet d'utiliser la POA afin 
de securiser la couche metier de maniere efficace et transparente. 

Enfin, Spring Security permet de rendre la securite completement transversale et declarative. 
Une application peut pratiquement etre developpee entierement sans se soucier de la securite, 
la configuration de celle-ci se faisant generalement dans un fichier dedie. 

Si nous reprenons les besoins de securite rappeles en debut de chapitre, Spring Security 
apporte les avantages suivants : 

• Gestion des utilisateurs : solution integree, complete et portable. 

• Securisation des requetes HTTP : disponible de maniere plus fine que dans la norme Java 
EE. 

• Securisation de la couche de service : API complete, qui s'integre dans les frameworks 
courants de POA. 

• Securisation de la couche de domaine : listes de controle d'acces (ACL), qui peuvent etre 
specifiees au niveau de chaque objet de domaine. 

• Controle du code execute : non pris en compte par Spring Security. Comme nous l'avons 
vu, cette fonction est rarement utile dans une application d'entreprise. 



Historique de Spring Security 

Le code de Spring Security s'appuie sur celui d'Acegi Security, un framework Open Source 
heberge par SourceForge. Acegi Security representait une solution de fait pour les problema- 
tiques de securite des applications fondees sur Spring, et c'est la raison pour laquelle son code 
a ete utilise pour constituer la solution de securite officielle de Spring. 

Si Acegi Security fournissait de nombreuses fonctionnalites et permettait de faire de la secu- 
rite une problematique transverse, son utilisation, fondee completement sur la configuration 
Spring 1.x, s'averait particulierement penible. La definition des contraintes de securite devait 



Spring Security J 
Chapitre 14 ■ 

passer par la declaration d'un grand nombre de Beans. La verbosite de la configuration 
d'Acegi Security etait aussi propice a de nombreuses erreurs. 

Spring Security remedie a ces inconvenients par 1' utilisation massive d'un schema XML 
dedie, avec tous les avantages qui en decoulent. La configuration de Spring Security est done 
beaucoup moins verbeuse et plus simple (avec, par exemple, Faide de la completion d'un 
editeur XML). 

Quand Acegi Security necessitait au minimum la declaration d'une dizaine de Beans pour 
fonctionner de la maniere la plus elementaire, nous allons voir que l'equivalent peut etre 
accompli en quelques lignes avec Spring Security. 

La version de Spring Security utilisee dans ce chapitre est la 2.0.4. 



Installation 

Spring Security est concu sous la forme d'un ensemble de fichiers JAR. L archive principale 
constitue le noyau, les autres archives fournissent F implementation des differents modules 
(liste de controle d'acces, integration avec des solutions de SSO, etc.). 

Voici quelques-uns des modules de Spring Security, qui prennent chacun la forme d'un JAR 
dans la distribution : 

• Core : le noyau de Spring Security, qui contient notamment le support pour la securisation 
des URL et des methodes. 

• Core Tiger : classes du noyau necessitant la version 1 .5 de Java (notamment pour la gestion 
des annotations). 

• Taglibs : des balises JSP pour Finterfacage avec Spring Security dans les vues d'une appli- 
cation. 

• ACL : gestion des listes de controle d'acces (Access Control List), pour la securisation des 
objets de domaines. 

La configuration de Spring Security commence par la declaration d'un filtre de servlet dans le 
fichier web.xml d'une application Web : 

<f ilter> 

<fil ter-name>springSecurityFil terChain</fil ter-name> 
<f i 1 ter-cl ass> 

org. springframework. web. filter. Delegating Filter Proxy 
</filter-class> 
</filter> 

( ... ) 

<filter-mapping> 

<f i 1 ter-name>springSecuri tyFi 1 terChain</f i 1 ter-name> 

<url -pattern>/*</url -pattern) 
</filter-mapping> 
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Cette configuration redirige F ensemble des requetes HTTP vers Spring Security. En interne, 
ce filtre delegue les requetes a un Bean nomme springSecurityFilterChain defini dans le 
contexte Spring. Ce Bean est automatiquement cree par Spring Security des que le schema 
XML de Spring Security est utilise. II est done essentiel de ne pas explicitement declarer un 
Bean portant ce nom. 

Pour que Spring Security soit operationnel, il faut bien sur qu'un contexte Spring soit declare 
dans le fichier web.xml (charge generalement par un ContextLoaderListener). 

Configuration de base 

Afin de rendre la securite la plus transversale possible, mais aussi de ne pas surcharger les 
fichiers de contexte Spring, il est recommande de centraliser la configuration de Spring Secu- 
rity dans un fichier dedie. Dans Tudu Lists, nous avons opte pour cette solution (le fichier 
s'appelle applicationContext-security.xml et se trouve dans le repertoire WEB-INF). 

Pour utiliser Spring Security, il faut d'abord declarer son schema XML : 

<beans : beans xmlns-" http://www.spri ngframework.org/schema/security" 

xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xmlns :beans=" http://www.spr ingframework.org/schema /beans" 
xsi :schemal_ocation=" 

http: //www. springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd 
http: //www. springframework.org/schema/security 
http://www.springframework.org/schema/security/spring- 
security.xsd"> 

(...) 

</beans : beans> 

Cette declaration permet d'utiliser directement (sans prefixe) les balises de Spring Security. 
Le fichier de configuration etant dedie a la securite, utiliser ce type de declaration permet 
d' avoir une syntaxe plus concise. 

Une configuration tres elementaire pour une application Web serait la suivante : 

<http auto-config="true"><— Q 

<intercept-url pattern-"/**" access="ROLE_USER" />^@ 
</http> 

<authenti cation-provider><— Q 
<user-service><— Q 
<user name="admin" password="mdp4admin" 
authori ties="ROLE_ADMIN, ROLEJJSER" /> 
<user name="tudu" password="mdp4tudu" 
authorities="ROLE_USER" /> 
</user-servi ce> 
</authentication-provider> 
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La configuration de la securite pour une application Web passe par la declaration d'un element 
http. L'attribut auto-config implique que Spring Security declare une configuration par 
defaut (Q), qui positionne notamment une authentification via un formulaire genere 
dynamiquement ; un filtre gere la deconnexion et un service pour se connecter automatique- 
ment grace a un cookie. 

Au repere Q, une regie d'acces est precisee : tout utilisateur doit posseder le role ROLEJJSER 
pour pouvoir consulter n'importe quelle URL. La syntaxe utilisee, /**, est dite « syntaxe 
Ant ». 

Les balises suivantes servent a definir un annuaire d'utilisateurs. Cet annuaire est tres simple- 
ment defini dans le fichierde contexte Spring. Labalise a ut hen ti cat ion -provider (0) precise 
que le user -service contenu (0) peut servirde source d' authentification. Dans labalise user- 
service sont definis deux utilisateurs. Le premier d'entre eux a pour identifiant admin, pour 
mot de passe mdp4admin et a deux roles, ROLEJSER et ROLE_ADMIN. 

Meme si ce genre d' annuaire d'utilisateurs n'est pas vraiment viable pour une application 
d'entreprise, il a le merite de pouvoir faire demarrer rapidement Fapprentissage de Spring 
Security. II peut aussi etre utilise en environnement de developpement ou a des fins de test. 

Les elements definis dans cette premiere configuration font partie integrante du framework 
Spring Security, dont nous verrons plus precisement 1' architecture globale par la suite. 

Les utilisateurs d'Acegi Security peuvent constater immediatement la difference. La balise 
http positionne un ensemble de filtres de servlet qu'il fallait avec Acegi declarer un a un et 
dans un ordre donne. 

Cette configuration peut convenir a une application simple, necessitant une authentification 
pour Fensemble de ses ecrans (puisque toutes les URL sont interceptees). Si l'application 
dispose d'un back-office reserve aux administrateurs et que Fensemble des URL de ce back- 
office commence par /admin/, il est possible de restreindre son acces en ajoutant une 
restriction : 

<http auto-config="true"> 
<intercept-url pattern-"/**" access="ROLE_USER" /> 
O'ntercepturl pattern="/admin/**" access="ROLE_ADMIN" /> 

</http> 

Nous allons ameliorer la securite de notre application en exploitant les possibilites de Spring 
Security, en commencant par le mecanisme d' authentification. 



Gestion de I' authentification 

Principes d'authentification de Spring Security 

Quand Spring Security est utilise dans une application Web, il positionne un filtre de servlet 
interceptant les requetes HTTP afin de verifier si l'utilisateur est habilite a consulter les diffe- 
rentes URL. Spring Security utilise un contexte de securite qui est positionne lors de 1' authen- 
tification de l'utilisateur. Ce contexte de securite contient notamment l'utilisateur et les roles 
{authorities) qui lui sont attribues. 
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Le composant effectuant Fauthentification dans Spring Security est un 
AuthenticationManager. L'interface AuthenticationManager est tres simple : 

package org. spri ngf ramework. security ; 

public interface AuthenticationManager { 

Authentication authenticate(Authentication authentication) 
th rows Authenti cati onExcepti on ; 

} 

La methode authenticate prend en parametre un objet Authentication qui contient les infor- 
mations d'authentification (le plus souvent un identifiant et un mot de passe). L'objet 
Authentication retourne par la methode authenticate contient des informations supplemen- 
taires une fois Fauthentification effectuee, notamment les roles de Futilisateur, auxquels on 
peut acceder via la methode Authenti cati on. getAuthori ties. II existe differentes implemen- 
tations d'Authentication, mais il s'agit plutot de classes manipulees en interne par Spring 
Security. 

Spring Security positionne par defaut un Provi derManager qui est une implementation compo- 
site d' AuthenticationManager. Le ProviderManager utilise en effet une liste de composants 
Authenti cati onProvider, auxquels il delegue Fauthentification. Spring Security fournit un 
ensemble de composants Authenti cati onProvider, pour les differentes technologies d'authen- 
tification qu'il supporte. 

Le diagramme UML illustre a la figure 14-1 resume cette modelisation et presente quelques 
composants AuthenticationProvider fournis par Spring Security. 

Voici une liste non exhaustive des composants AuthenticationProvider fournis dans Spring 
Security : 

• LdapAuthenti cati onProvider : effectue une authentification en utilisant un annuaire 
implementant le protocole LDAP. Les moyens de s'authentifier avec LDAP etant 
nombreux, ce fournisseur delegue son travail a d'autres classes et est done fortement 
parametrable. 

• JaasAuthenticationProvider : effectue une authentification au moyen d'un fichier de 
configuration JAAS. 

• CasAuthenticationProvider : implemente une authentification fondee sur la solution de 
Single Sign On JA-SIG CAS (Central Authentication Server). 

• DaoAuthenti cati onProvider : delegue la recuperation des informations sur Futilisateur a un 
UserDetai 1 sServi ce puis effectue la verification du mot de passe a partir de ces informations. 

La plupart des composants AuthenticationProvider effectuent Fauthentification, e'est-a-dire 
qu'ils gerent la verification de Fidentite de Futilisateur. lis deleguent generalement la recupe- 
ration des informations de Futilisateur a un UserDetailsService, notamment pour connaitre 
les roles de Futilisateur. 
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Figure 14-1 

L'authentification avec Spring Security 

Les supports d'authentification de Spring Security viennent done directement des implemen- 
tations de UserDetailsService. Spring Security propose les implementations suivantes : 

• InMemoryDaoImpl : recupere les informations a partir d'une structure de donnees en 
memoire. II s'agit de 1' implementation utilisee dans notre configuration de depart, ou les 
utilisateurs sont definis dans le contexte Spring. 

• JdbcDaoImpl : recupere les informations a partir d'une base de donnees. Cette classe est 
parametrable afin de s' adapter aux differentes structures des tables utilisateur. 

• LdapUserDetai 1 sServi ce : recupere les informations utilisateur en interrogeant un annuaire 
LDAP. Cela suppose que 1' annuaire dispose de sufnsamment d' informations, notamment 
les roles de F utilisateur. 



Positionnement des fournisseurs 



Comme Spring Security positionne par defaut un ProviderManager, il est possible, avec la 
balise authentication-provider, d'ajouter des composants AuthenticationProvider, qui 
feront automatiquement partie de la chaine d'authentification. 



Technologies d'integration 

Partie IV 



II faut ensuite preciser le UserDetailsService utilise, soit de maniere explicite, comme dans 
notre exemple de configuration par defaut (definition a l'aide de balises internes), soit en 
faisant reference a un Bean implementant Finterface UserDetailsService, avec l'attribut user- 
service-ref : 

<authenti cation -provider user-service-ref ="myUserDetai 1 sServi ce" /> 

<beans :bean id-" jdbcUserDetai 1 s Service" 
class-"org.springframework.security.userdetails. jdbc. JdbcDaoImpl "> 
(...) 
</beans : bean> 

Si nous souhaitons utiliser une implementation bien specifique d'AuthenticationProvider, il 
est necessaire de passer par la creation d'un Bean ordinaire de Spring (avec la balise bean). Or, 
de cette maniere, 1' Authentication Provider declare n'est pas automatiquement ajoute a la pile 
du ProviderManager par defaut. 

Pour remedier a ce probleme, il faut ajouter la balise custom -authentication -provider dans la 
declaration du Bean : 

<beans :bean id="myAuth Provider" cl a ss=" custom. AuthProvider"> 
<custom- authentication -provider /> 

(...) 
</beans : bean> 

Authentif ication via une base de donnees 

Si 1' application que nous developpons n'est pas connectee a un systeme de securite fourni par 
Fentreprise, le plus simple est de stocker les donnees d'authentification au sein de la base de 
donnees. 

Spring Security propose une implementation de UserDetailsService effectuant des requetes 
SQL pour recuperer les donnees de l'utilisateur. Afin d'etre le plus adaptable possible, il est 
possible de parameter les requetes a effectuer. Ces requetes sont au nombre de deux : une 
pour recuperer les donnees utilisateur, 1' autre pour recuperer les roles de l'utilisateur. 

Voici comment utiliser cette implementation : 

<authenti cat ion -provide r> 

<jdbc- user -service data- source -ref="dataSource" 

users-by-username-query="SELECT login, password, enabled FROM tuser WHERE login = ?" 
authorities-by-username-query="SELECT tuser_login,roles_role FROM tuser_role 
WHERE tuserjogin = ?" 
/> 

</authentication-provider> 

Dans cet exemple, nous utilisons la balise jdbc-user-service imbriquee avec authentication- 
provider. Le UserDetailsService JDBC necessite pour fonctionner une DataSource, que nous 
pouvons assigner avec l'attribut data-source-ref. 
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La premiere requete SQL (attribut users -by -name -query) doit retourner trois valeurs : le login, 
le mot de passe et si l'utilisateur est active ou non. La seconde requete (attribut authorities- 
by-username-query) a pour but de retrouver des couples login-role, un utilisateur pouvant 
avoir plusieurs roles. Du fait de 1' utilisation de labalise authentication-provider, le fournis- 
seur sera automatiquement integre a la chaine d'authentification du ProviderManager. 

Le UserDetai 1 sServi ce JDBC permet de repondre a la plupart des besoins. Dans le cas d'une 
base de donnees utilisateur plus complexe, il est plus avantageux de construire sa propre 
implementation deUserDetailsService. 

Authentification via LDAP 

Les annuaires LDAP sont aujourd'hui tres repandus en entreprise. lis permettent de disposer 
d'un depot central des utilisateurs au lieu que chaque application dispose de son propre refe- 
rentiel. II n'est cependant pas rare qu'un service d'entreprise (service de Single Sign On, par 
exemple) constitue le point d'entree pour F authentification. Dans ce cas, LDAP n'est pas 
directement utilise par les applications. 

Le support pour LDAP de Spring Security permet de s'authentifier et de recuperer des infor- 
mations sur l'utilisateur. De facon generale, 1' authentification avec un annuaire peut se faire 
suivant deux approches : 

• Binding : equivalent d'une connexion dans le monde LDAP, avec les parametres d'authen- 
tification de l'utilisateur (nom d'utilisateur et mot de passe). Si le binding reussit, l'utilisa- 
teur est considere comme authentifie. Avec cette approche, F authentification est finalement 
deleguee a F annuaire. 

• Comparaison du mot de passe : consiste a recuperer les informations utilisateur depuis 
Fannuaire LDAP et a comparer le mot de passe fourni par l'utilisateur. L'applicatif a done 
ici une place plus importante qu'avec le binding, puisqu'il effectue lui-meme la compa- 
raison. 

Aucune des deux approches n'a plus d'avantages que F autre. L approche par binding etant la 
plus courante, e'est celle-ci que nous allons etudier en premier. Spring Security supporte bien 
sur les deux approches. 

Authentification LDAP par binding 

Afin d'illustrer notre propos, voici un fichier LDIF (format d'echange de donnees des annuaires 
LDAP) contenant les entrees de notre annuaire : 

dn: ou=peopl e ,o=tudu 

objectCl ass : organ i zati onal Uni t 

ou: people 

dn : cn=acogol uegnes ,ou=peopl e,o=tudu 
objectCl ass : organizational Person 
objectCl ass: person 
objectCl ass: i netOrgPerson 
objectCl ass: top 
cn: acogoluegnes 
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sn: arnaud 
I userPassword: : bWRwNGFybm8= 

Sa connaissance permettra au lecteur de comprendre plus facilement les requetes effectuees 
par la suite. 

Spring Security propose un type d'AuthenticationProvider specifique pour acceder a un 
serveur LDAP. II est utilisable avec la balise 1 dap -authentication -provider. Cet 
AuthenticationProvider LDAP necessite une connexion vers un serveur (on parle aussi de 
contexte LDAP). 

Voyons done en premier lieu comment definir ce contexte LDAP avec Spring Security. La 
definition la plus courante est la suivante : 

<ldap-server url="ldap://localhost:389/" /> 

En interne, cette balise cree une ContextSource, interface du projet Spring LDAP permettant 
de creer des contextes LDAP. Cette definition amene Spring Security a acceder de facon 
anonyme au serveur LDAP. II est possible de configurer un annuaire LDAP pour qu'il refuse 
les connexions anonymes. II faut dans ce cas preciser un DN (Distinguished Name) adminis- 
trateur et le mot de passe associe : 

<1 dap -server url="ldap: //l ocal host : 389/" 
manage r - dn-" ui d=admi n ,ou=sy stem" manager- pa ssword=" secret" /> 

Spring Security permet aussi de lancer un serveur LDAP embarque, a des fins de test ou de 
demonstration. L annuaire LDAP utilise etant Apache DS, il faut que les fichiers JAR corres- 
pondants soient dans le classpath. Des lors que Fattribut url n'est pas precise, Spring Security 
utilise un serveur LDAP embarque. 

II est possible de preciser la racine a utiliser ainsi que le chemin d'un fichier LDIF, arm que le 
serveur embarque contienne des donnees : 

<ldap-server 

root="o=tudu" ldif="classpath:/tudu/security/tudu.ldif " /> 

Le cas le plus frequent reste cependant la connexion directe a un serveur LDAP, dont il faut 
preciser FURL. 

Une fois la ContextSource creee via la balise 1 dap-server, il est possible de definir 
l'Authenti cationProvider LDAP qui va effectuer F authentification et le chargement des roles. 
II faut pour cela utiliser soit la balise ldap-authentication-provider directement, soit une 
balise authentication-provider dans laquelle s'imbrique la balise ldap-user-service. Ces 
deux syntaxes sont equivalentes, et nous allons utiliser la premiere. 

Spring Security permet d'effectuer le binding de deux facons. La premiere consiste a preciser 
un motif de recherche avec Fattribut user-dn-pattern : 
<1 dap -authentication -provider 

userdnpattern="cn={0} ,ou=people,o=tudu" /> 

Le parametre {0} indique le nom de Futilisateur. Cette methode est simple mais a pour limita- 
tion que Fensemble des utilisateurs doit se trouver dans le meme nceud. On peut remedier a 
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cet inconvenient avec la deuxieme facon, qui consiste a donner un nitre de recherche et un 
nceud de base pour effectuer cette recherche : 
<ldap-authenti cati on -provider 
user- sea rch-fi 1 ter="(cn={0} ) " 
user -sea rch - base=" ou=peopl e,o=tudu" /> 

La recherche est alors recursive, ce qui permet de stacker les utilisateurs dans une structure 
arborescente. 

La recuperation des roles de Futilisateur se fait en parametrant la balise ldap-authentication- 
provider afin qu'elle puisse effectuer les requetes LDAP appropriees. 

Voici un complement du fichier LDIF de notre annuaire, definissant des nceuds pour les roles : 

dn: ou=groups ,o=tudu 
objectCl ass : organ i zati onal Uni t 
objectClass: top 
ou: groups 

description: Tudu Lists User Groups 

dn: cn=admin,ou=groups,o=tudu 
objectClass: groupOf Names 
objectClass: top 
cn: admin 

description: Tudu Admin Groups 

member: cn=acogol uegnes ,ou=people,o=tudu 

ou: admin 

dn: cn=user,ou=groups ,o-tudu 
objectClass: groupOfNames 
objectClass: top 
cn: user 

description: Tudu Admin Groups 
member: cn=acogol uegnes ,ou=peopl e ,o=tudu 
member : cn=templ th , ou=peopl e , o=tudu 
ou: user 

Deux groupes sont definis, « admin » et « user ». Voici comment parameter 
1'AuthenticationProvider LDAP pour recuperer convenablement les roles des utilisateurs a 
partir des nceuds precedemment definis : 

<ldap-authenti cati on -provider 

user-dn-pattern="cn={0} ,ou=peopl e,o=tudu" 
group -sea rch - base=" ou=groups ,o=tudu" 
group- rol e-attribute="cn" 
group -sea rch-fi 1 ter=" (member={0) ) " 

/> 

L'attribut group-search-base indique le nceud de base des groupes. Lattribut group-role- 
attribute indique l'attribut LDAP qui va etre utilise par Spring Security pour definir le role 
dans l'application, sous forme de chaine de caracteres. Enfin, l'attribut group-search-filter 
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permet d'indiquer un filtre de recherche permettant de retrouveiTutilisateur. Le parametre {0} 
indique ici le DN (Distinguished Name) de l'utilisateur, et pas seulement son identifiant tel 
qu'il est passe a Spring Security. La translation est de toute facon prise en charge par Spring 
Security. 

En prenant les donnees de notre fichier LDIF, apres authentication de l'utilisateur 
« acogoluegnes », on trouve les roles R0LE_ADMIN et R0LE_USER. Cela ne concorde pas avec les 
groupes dermis dans l'annuaire, qui sont nommes respectivement « admin » et «user». 
Spring Security opere une transformation sur les roles : il les passe en majuscules et leur 
ajoute un prefixe. Si la transformation en majuscules ne peut etre facilement supprimee, il est 
possible de modifier le prefixe, qui est par defaut R0LE_, avec Fattribut rol e-pref ix : 

<1 dap -authentication -provider 

user-dn-pattern="cn={0} , ou=peopl e,o=tudu" 
group- sea rch-base="ou=groups ,o=tudu" 
group- rol e-attribute="cn" 
g roup- sea rch-f i 1 ter=" (member={0} ) " 
role-prefix="PROFIL_" /> 

Authentification LDAP par comparaison de mot de passe 

Avec Spring Security, le passage de 1' authentification LDAP par binding a F authentification 
par comparaison de mot de passe se fait tres simplement en ajoutant la balise password- 
compare dans ldap-authentication-provider : 

<1 dap -authentication -provider 

user-dn-pattern="cn={0} ,ou=peopl e,o=tudu" 

group- sea rch-base="ou=groups ,o=tudu" 

group- rol e-attribute="cn" 

group -sea rch-f i 1 ter=" (member={0} ) " 

> 

<password- compare hash="pl aintext" 
password -attribute-'userpassword" /> 

</l dap-authenti cation-provider> 

II est possible de preciser la comparaison de mot de passe avec l'attribut hash. Notre fichier 
LDIF ne comportant pas de hachage pour les mots de passe, nous utilisons la valeur 
plaintext. Spring Security supporte les principaux algorithmes de hachage (MD5 et famille 
SHA). Nous indiquons aussi l'attribut dans lequel se trouve le mot de passe avec password- 
attribute. 

Le support de Spring Security pour 1' authentification LDAP permet de repondre a la plupart 
des besoins. Cependant, pour des cas plus complexes, il est possible de configurer directement 
des Beans Spring Security sans passer par le schema XML dedie. L'extension des possibilites 
du support LDAP se fait alors au detriment de la facilite de configuration. 

Nous allons revoir une authentification par comparaison de mot de passe et le chargement des 
roles avec ce mode de configuration. Dans les exemples suivants, le schema beans est le 
schema par defaut tandis que le schema de Spring Security est prefixe par sec. 
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II faut maintenant definir explicitement un Authenti cati onProvi der LDAP, avec la declaration 
d'un Beande type LdapAuthenti cati onProvi der : 

<bean id-"ldapAuthProvider" class-" 

org. spr i ngf ramewo rk. secur ity. providers.! dap. LdapAuthenti cati onProvi der "> 

<constructor-arg ref="authenti cator" /> 

<constructor-arg ref-"popul ator" /> 

<sec: custom- authenti cat ion -provider /> 
</bean> 

Un LdapAuthenti cati onProvi der delegue son travail a deux autres Beans. Le premier est une 
dependance obligatoire, il s'agit d'un LdapAuthenti cator, qui, comme son nom Findique, 
effectue rauthentification. Le deuxieme est un LdapAuthoritiesPopul ator qui permet de recu- 
perer les informations sur l'utilisateur dans l'annuaire (notamment les roles). Afin que 
1'AuthenticationProvider LDAP soit rajoute a la pile du ProviderManager par defaut, nous 
ajoutons la balise sec: custom- authenti cat ion -provider dans la declaration. 

Spring Security fournit deux implementations de LdapAuthenti cator : le BindAuthenti cator 
qui gere rauthentification avec un binding et le PasswordComparisonAuthenti cator. 

Nous utilisons pournotre exemple un PasswordComparisonAuthenticator : 

<sec:l dap -server url="l dap: //I ocal host : 10389/" 

id="contextSource" /><— Q 
<bean id="authenticator" class=" 

org. sp r i ngf ramewo r k. secur ity. providers.! dap. authenti cator. Pa sswordCompari son Aut he 
ti cator "> 

<constructor-arg ref-"contextSource" /><— Q 

<property name-"userDnPatterns"> 

<list> 

<val ue>cn={0} ,ou=peopl e,o=tudu</val ue><— Q 
</list> 
</property> 

<property name="passwordAttri buteName" val ue="userPassword" /><— Q 
<property name="passwordEncoder" ref="passwordEncoder" /><— Q 
</bean> 

<bean id="passwordEncoder" class=" 

org. spri ngf ramewo rk. secur ity. providers. encoding. PI a intext Pas swordEncoder" /><— Q 

Avec une declaration explicite du PasswordComparisonAuthenti cator, il faut nommer la 
ContextSource (Q) et la passer au constructeur (Q). Pour recuperer l'utilisateur, nous utili- 
sons la methode par motif de recherche (Q). II est possible de preciser le nom de l'attribut 
correspondant au mot de passe. Conformement a notre fichier LDIF, nous utilisons l'attribut 
userPassword (©). Nous parametrons la comparaison de mot de passe avec la propriete 
passwordEncoder (©). C'est cet objet qui fait la comparaison et qui prend en compte un 
hachage potentiel du mot de passe dans l'annuaire LDAP. Par defaut, un 
LdapShaPasswordEncoder est utilise. Notre fichier LDIF ne comportant pas de hachage pour les 
mots de passe, nous utilisons un PlaintextPasswordEncoder (0). 
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Nous constatons que l'utilisation d'un PasswordComparisonAuthenticator permet de configu- 
rer tres finement l'authentification, mais que cette configuration s'avere beaucoup plus techni- 
que qu'avec le schema XML. 

Afin de recuperer les roles de l'utilisateur, il faut completer la configuration avec un 
LdapAuthoritiesPopulator : 

<bean id="popul ator" class=" 

org. springframework.security.l dap. popul ator. Def aul tLdapAuthoritiesPopul ator "> 

<constructor-arg ref="contextSource" /> 

<constructor-arg value="ou=groups,o=tudu" /> 

<property name="groupRoleAttribute" value="cn" /> 

<property name="groupSearchFi 1 ter" val ue=" (member={0} ) " /> 
</bean> 

II faut passer au constructeur du LdapAuthoritiesPopulator la ContextSource et le nceud de 
base des groupes (equivalent de l'attribut group-search-base de la balise ldap- 
authentication-provider). Les deux proprietes groupRoleAttribute et groupSearchFilter 
sont les equivalents des attributs de ldap-authentication-provider. 

S'il est plus difficile de configurer explicitement un LdapAuthoritiesPopulator qu'avec le 
schema XML de Spring Security, il est possible de le parameter plus finement : 

<bean id="popul ator" class-" 

org. springframework.security.l dap. popul ator. DefaultLdapAuthoritiesPopul ator "> 
(...) 

<property name="convertToUpperCase" val ue="fal se" /> 
<property name="rolePrefix" val ue="prof i 1_" /> 
<property name="def aul tRol e" val ue="prof i l_def aul t" /> 

</bean> 

Les proprietes ajoutees permettent respectivement de laisser les roles en minuscules, regler le 
prefixe et attribuer un profil a tous les utilisateurs. 

Authentif ication via une implementation specif ique 

Afin d'integrer le referentiel utilisateur d'une application avec Spring Security, il est possible 
d'implementer l'interface UserDetailsService. Nous allons prendre comme exemple Fimple- 
mentation de Tudu Lists. 

Voici l'ossature de cette implementation : 
package tudu. security ; 

import org. springf ramework.dao. Da taAccess Except ion ; 

import org.springframework.security.userdetails.UserDetails; 

import org.springframework.security.userdetai Is. UserDetailsService; 

import o rg. spr i ngf ramewo rk.security .userdetai Is. Use rnameNot Found Except ion; 

import t udu. service. Use rManager; 

public class UserDetai 1 sServi celmpl implements UserDetailsService { 
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private UserManager userManager = null; 

public void setUserManager(UserManager userManager) { 
thi s . userManager = userManager; 

} 

public UserDetails loadUserByUsername(String login) 

throws UsernameNotFoundException, DataAccessException { 
(...) 

} 

} 

Dans Tudu Lists, l'interface UserManager definit les services d'acces au referentiel utilisateur, 
il est done naturel de Futiliser dans UserDetail sServicelmpl . 

Voici 1' implementation de la methode loadUserByUserName : 

public UserDetails loadUserByUsername(String login) 

throws UsernameNotFoundException, DataAccessException { 
login = 1 ogin . toLowerCase( ) ; 
User user = null; 
try { 

user = userManager. findUser(login) ;<— © 
} catch (ObjectRetrieval Fai 1 ureException orfe) { 
throw new UsernameNotFoundException( 

"User '" + login + "' could not be found." 
);<-© 

} 

user. set La stAccess Da te ( Ca 1 endar. get Instance ( ) .getTime( ) ) ; 
userManager. updateUser( user) ;<— © 

Set<Role> roles = user.getRolesO; 

GrantedAuthority[] arrayAuths = new GrantedAuthori ty[rol es .size( )] ; 

int index = 0; 

for (Role role : roles) { 

arrayAuths[i ndex++] = new GrantedAuthoritylmpl ( 
role.getRole( ) 

):<-© 

} 

return new org. springframework. security. userdetails.User( 
1 ogin .user .get Pas sword ( ) .user . i sEnabl ed( ) , 
true, true, true, 
arrayAuths) ;<— Q 



La methode loadUserByUsername accepte en parametre l'identifiant (login) de l'utilisateur. 
Nous passons cet identifiant a la methode f indUser du UserManager de Tudu Lists (©) afin de 
recuperet - un objet de domaine User de Tudu Lists. Afin d'honorer le contrat de 
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loadUserByUserName, nous relancons une UsernameNotFoundException si aucun utilisateur ne 
correspond a cet identiflant (Q). 

Si un utilisateur correspond a cet identifiant, nous en profitons pour mettre a jour sa date de 
derniere connexion (©). II faut ensuite recuperer les roles de 1' utilisateur et les mettre sous la 
forme de GrantedAuthority, une interface propre a Spring Security. C'est ce qui est fait au 
repere ©, ou Ton cree des GrantedAuthori ty Impl a partir des objets Rol e (de Tudu Lists). 

Enfin, au repere @. un User (classe Spring Security) est cree. Les premiers parametres sont 
Fidentifiant, le mot de passe et un drapeau pour savoir si Futilisateur est bien active. Les trois 
drapeaux suivants (tous mis a vrai, parce que Tudu Lists ne les exploitent pas) informent 
Spring Security respectivement sur la non-expiration du compte utilisateur, la non-expiration 
de son systeme d'authentification (par exemple pour un certificat numerique) et le non- 
verrouillage du compte. 

La configuration du contexte Spring se fait alors de la facon suivante : 
<authenti cation -provider user-servi ce-ref="userDetai 1 sService" /> 

<beans :bean id="userDetai 1 sService" 

cl ass-" tudu. security .User Detai 1 sService Impl "> 
<beans:property name="userManager" ref="userManager" /> 
</beans : bean> 

La balise authentication-provider peut se « brancher » sur un Bean implementant 
UserDetailsService avec Fattribut user-servi ce- ref. Notre implementation est declaree 
comme un Bean standard et se voit injecter le UserManager de Tudu Lists (sa declaration ne 
figure pas ici). 

II est important de comprendre que notre implementation de UserDetailsService n'a d' autre 
fonction que de recuperer les informations necessaires a Spring Security pour prendre ces 
decisions sur Fauthentification et les autorisations. II est possible de configurer 
1'AuthenticationProvider pour qu'il exploite, par exemple, un PasswordEncoder car les mots 
de passe en base de donnees sont haches. 

Cette separation stricte des responsabilites garantit un interfacage simple avec le referentiel 
utilisateur de Tudu Lists et permet de gerer de facon completement declarative la securite. 

Hachage des mots de passe 

Le hachage est une transformation effectuee sur des donnees qui debouche sur une chaine de 
caracteres de faille fixe. Le hachage est utilise pour des calculs d'integrite (on parle aussi de 
calcul d'empreinte) ainsi que pour les signatures numeriques. Dans notre cas (stockage des 
mots de passe), le hachage a deux proprietes interessantes : 

• La non-reversibilite : il est impossible de revenir aux donnees d'origine a partir de 
Fempreinte. 

• Le faible taux de collision : il est (en theorie) impossible que des donnees differentes aient 
la meme empreinte. Cette propriete est directement dependante de Falgorithme de hachage 
utilise, certains ay ant des taux de collision plus faibles que d'autres. 



Spring Security 

Chapitre 14 



En considerant un mot de passe comme une donnee confidentielle, que seul l'utilisateur 
concerne doit connaitre, il est essentiel de le stacker sous forme hachee. II est alors impossi- 
ble, meme pour les administrateurs du systeme, de retrouver le mot de passe. C'est d'ailleurs 
pour cela qu'il est necessaire de generer un nouveau mot de passe si on Foublie, puisque 
personne n'est capable de le retrouver. Par abus de langage, on dit souvent que les mots de 
passe sont cryptes, mais le terme exact est hache. 

Quand un utilisateur soumet un mot de passe pour s'authentifier, ce mot de passe est hache 
puis compare directement avec l'empreinte stockee. Si les deux sont identiques, le mot de 
passe entre est correct. 

Spring Security permet de gerer le hachage des mots de passe au niveau des composants 
AuthenticationProvider. Comme explique precedemment, un AuthenticationProvider dele- 
gue la recuperation des informations a un UserDetai 1 sServi ce. Ce dernier ramene les donnees 
telles qu'elles sont dans le depot et 1'AuthenticationProvider gere alors la verification. 

Le parametrage de Falgorithme de hachage se fait avec la balise password-encoder au sein de 
labalise authentication-provider : 

<authentication-provider> 

<password-encoder hash="sha" /> 

<user-service> 

<user name="acogol uegnes" 
Password="bdl9c801b24f23ff73f2e2aeac0577a8131b92b2" 
authorities-" ROLE_ADMINV> 
</user-service> 
</authentication-provider> 

Dans notre exemple, nous emulons un referentiel utilisateur avec la balise user-service. Le 
mot de passe de l'unique utilisateur est une empreinte obtenue avec l'algorithme SHA-1 (le 
mot de passe est « mdp4arno »). Nous indiquons cela a 1'AuthenticationProvider avec l'attri- 
but hash de password-encoder, afin qu'il puisse exploiter correctement l'information obtenue 
par son UserDetai IsService. 

Spring Security supporte la plupart des algorithmes de hachage (MD5, famille SHA). Nous 
recommandons F utilisation des algorithmes de la famille SHA (SHA-1, SHA-256 et SH-512), 
qui seront vraisemblablement les plus surs pour les annees a venir. 

Hacher simplement les mots de passe dans le referentiel utilisateur n'est cependant pas 
toujours suffisant, car cela ne protege pas des attaques par dictionnaire. Ces attaques consis- 
tent a tester des dictionnaires de mots de passe deja haches avec les mots de passe haches du 
referentiel d'une application. Cette attaque compte sur la faiblesse des mots de passe utilises, 
par exemple des noms communs ou des noms propres. II n'est pas possible de contrecarrer 
completement ces attaques potentielles, mais il est cependant possible de les rendre beaucoup 
plus longues a s'executer. 

Une premiere parade passe par l'utilisation d'un grain de sel. Cela consiste a ajouter une 
chaine de caracteres au mot de passe avant qu'il ne soit hache. Spring Security peut etre para- 
metre pour prendre en compte le grain de sel : 
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<password-encoder hash="sha"> 

<salt-source system-wide="grain de sel"/> 
</password- encode r> 

Pour Spring Security, cela signifie que le mot de passe « mdp4arno » est en fait devenu 
« mdp4arno{ grain de sel} » avant d'etre hache. Nous avons ici un grain de sel fixe. La valeur 
du grain de sel doit normalement etre plus complexe et surtout eviter les noms communs 
(privilegier des lettres et des chiffres sans signification). Si le grain de sel est connu par un 
attaquant potentiel, celui-ci devra hacher a nouveau tout son dictionnaire, ce qui lui prendra 
plus de temps que sans grain de sel. 

Le grain de sel fixe est une premiere etape, mais il est plus sur d'utiliser un grain de sel varia- 
ble, c'est-a-dire propre a chaque mot de passe. Avec un grain de sel fixe, deux mots de passe 
identiques auront la meme empreinte, ce qui constitue une vulnerabilite pour les attaques 
fondees sur le paradoxe des anniversaires. 

Avec Spring Security, il est tres simple d'utiliser un grain de sel variable, qui peut etre recu- 
pere d'une des proprietes du compte utilisateur, par exemple son identifiant : 

<password-encoder hash="sha"> 

<sal t-source user-property="username" /> 
</password- encode r> 

Le mot de passe « mdp4arno » du compte « acogoluegnes » devient des lors 
« mdp4arno{acogoluegnes} ». Avec un grain de sel variable, les attaques par dictionnaires 
deviennent encore plus longues qu'avec un grain de sel fixe. 

Spring Security permet un parametrage plus fin de l'objet effectuant la verification du mot de 
passe, avec la configuration explicite d'un Bean implementant l'interface PasswordEncoder. 

Si nous voulons, par exemple, utiliser l'algorithme de hachage SHA-512, ce qui n'est pas 
directement possible avec le schema de Spring Security, il faut passer par la declaration et la 
configuration du ShaPasswordEncoder fourni dans Spring Security : 

<authentication-provider> 

<pas sword -encoder ref="passwordEncoder" > 

<salt-source user-property="username" /> 
</pas sword- encode r> 
(...) 

</authentication-provider> 

<beans:bean id="passwordEncoder" class=" 

org.springf ramework. security .providers .encoding.ShaPasswordEncoder"> 

<beans:constructor-arg value="512" /> 
</beans : bean> 

II existe d'autres techniques pour rendre les attaques par dictionnaire beaucoup plus difficiles 
et longues, dont l'une consiste a effectuer plusieurs iterations de hachage (jusqu'a plusieurs 
milliers). Le framework Jasypt (http://www.jasypt.org/) propose un excellent support pour le 
hachage des mots de passe et s'interface avec Spring Security avec des implementations de 
PasswordEncoder. 
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Securite d'une application Web 

Spring Security positionne un ensemble de nitres de servlet permettant de gerer tres flnement 
la securite d'une application Web. Nous avons vu precedemment les differents moyens 
d'authentifier un utilisateur. Nous allons voir maintenant comment exploiter les systemes 
d'authentification avec la configuration des differents filtres de Spring Security. 

Configuration automatique 

La configuration automatique de Spring Security permet de configurer tres rapidement une 
politique de securite pour une application : 

<http auto-config="true"> 

<intercept-url pattern-"/**" access="ROLE_USER" /> 
</http> 

<authenti cat ion -providers 
(...) 

</authentication-provider> 
La configuration precedente est equivalente a la configuration suivante : 
<http> 

<intercept-url pattern-"/**" access="ROLE_USER" /> 
<form-login /> 
<anonymous /> 
<http-basic /> 
<logout /> 
<remember-me /> 
</http> 

<authentication-provider> 
(...) 

</authentication-provider> 

La configuration automatique positionne un ensemble de filtres frequemment utilises dans une 
application Web. Nous allons etudier chacun de ces nitres. 

Interception des URL 

Dans la configuration HTTP, la balise intercept-url permet de definir les regies d'intercep- 
tion a appliquer sur un ensemble d'URL. La syntaxe de definition des URL est celle populari- 
see par Ant pour la designation des fichiers. Voici quelques exemples de cette syntaxe pour la 
designation d'URL : 

• /** : l'ensemble des URL ; 

• /admin/** : l'ensemble des URL se trouvant sous le chemin « admin » ainsi que ses sous- 
chemins ; 

• /*del ete* : toutes les URL contenant le mot « delete ». 
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Pour que la securisation par URL fonctionne, il faut decider de conventions de nommage, par 
exemple par module fonctionnel. Les URL sont alors de type /frontoffice/accueil .htm, / 
backof f i ce/gestionCommandes . htm, /admin/gestionUti 1 isateurs . htm, etc. 

Lattribut access permet de definir les attributs d'acces a Fensemble des URL interceptees. 
Par defaut, les attributs d'acces correspondent a un ou plusieurs roles que doit posseder 
Futilisateur : 

<intercept-url 

pattern="/edi t Post . html 

access=" R0LE_ADMI N , ROLE_MODERATEUR" /> 

Afin d' assurer la confidential! te des donnees qui passent sur le reseau, Spring Security 
propose un mecanisme permettant d'imposer le passage sur HTTPS d'un ensemble d'URL : 

<intercept-url pattern="/login.htm" requi res-channel="https" /> 

Avec cette configuration, l'URL /login. htm passera obligatoirement sur HTTPS, meme si un 
utilisateur Finterroge en HTTP (Spring Security imposera le canal utilise). Pour que le 
routage se fasse correctement, Spring Security doit connaitre le port HTTPS correspondant au 
port HTTP. Par defaut, les correspondances sont les couples 80/443 (ports standards HTTP et 
HTTPS) et 8080/8443. 

II est possible de configurer ces correspondances avec la balise port-mappings : 

<port-mappings> 

<port-mapping http="81" https="444"/> 
</port-mappings> 

Avec le reglage precedent, si une URL necessitant HTTPS est consultee en HTTP sur le port 
81, Spring Security saura qu'il faut utiliser le port 444 du serveur pour obtenir HTTPS. 

La securisation est une chose, mais il peut etre interessant d'imposer le protocole HTTP pour 
des donnees peu sensibles, car le cryptage impose par HTTPS est couteux en ressources 
processeur. 

Voici un exemple de configuration imposant HTTPS pour la page de login et pour le back- 
office d'une application, mais obligeant a passer par HTTP pour le front-office : 

<i intercept -url pattern="/l ogi n . htm" requi res- channel ="https"/> 

<intercept-url pattern="/back/**" requires-channel="https" access-"ROLE_ADMIN" /> 

<intercept-url pattern="/f ront/**" requires-channel="http" access="ROLE_USER" /> 

Recuperation du contexte de securite 

Les filtres positionnes par Spring Security savent comment interagir avec le contexte de secu- 
rite. II peut aussi etre utile a une application de pouvoir acceder a ce contexte, ne serait-ce que 
pour savoir qui est l'utilisateur connecte. 
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S'il est possible d'acceder ail contexte de securite via la session HTTP, il est preferable d'y 
acceder en utilisant un appel statique sur la classe SecurityContextHolder : 

I Authentication auth = Securi tyContextHol der . getContext( ) . getAuthentication( ) ; 

Avec l'objet Authenti cati on, il est possible d'acceder a diverses informations sur l'utilisateur 
(identifiant, mot de passe) et a ses roles. Cet appel statique masque la mecanique sous-jacente 
de recuperation du contexte. Par defaut, le contexte de securite est stocke dans une variable 
propre au thread courant (thread local). Spring Security propose d'autres moyens de stockage 
et de recuperation du contexte via le motif de conception strategie, qui est utilise par 
SecurityContextHol der. 

Authentification HTTP basique 

Le protocole HTTP inclut la notion d' authentification basique, qui permet a un client HTTP 
de s'authentifier aupres d'un serveur Web. Spring Security implemente ce type d' authentifica- 
tion en renvoyant le code de statut correspondant a une authentification HTTP basique (401), 
provoquant ainsi l'affichage d'une invite cote client. 
L' authentification HTTP basique se configure de la maniere suivante : 

<http> 
(...) 

<http-basic /> 
</http> 

L' authentification basique a l'avantage de faire partie du protocole HTTP, elle n'est cependant 
pas tres securisee et doit etre ecartee pour des applications sensibles. 

Authentification avec formulaire 

L' authentification avec formulaire affiche un formulaire demandant l'identifiant et le mot de 
passe d'un utilisateur. Sa forme de configuration la plus simple est la suivante : 

<http> 
(...) 

<form-login /> 
</http> 

Avec la configuration precedente, Spring Security redirige toute URL protegee vers un formu- 
laire cree automatiquement. La balise form-1 ogin dispose de parametres permettant de l'adapter a 
toute application : 

<http> 
(...) 

<form- login 
1 ogi n - pa ge="/ login. htm" 

authenti cati on -fai 1 ure-url=" /authenti cati on Fai 1 ure. htm" 

defaul t- target -url="/wel come. htm" 

1 ogin- process! ng-url="/j_todo_authenti cation_check" 

/> 
</http> 
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Voici la description de chacun de ces parametres : 

• login -page : precise une URL affichant le formulaire de connexion. Ce formulaire doit 
contenir les champs j_username pour l'identifiant et j_password pour le mot de passe de 
l'utilisateur. Quand le formulaire est soumis il doit appeler (parametre action de la balise 
HTML form) l'URL effectuant 1'authentification. Par defaut, cette URL est j_spr1ng_ 
secun'ty_check. Generalement, les applications affichent un lien dans les pages publiques 
vers cette URL, arm d'afficher le formulaire d'authentification. 

• authentication-failure-url : precise FURL vers laquelle Spring Security redirige en cas 
d'echec de 1'authentification. II s'agit generalement de la meme URL que login -page, avec 
un parametre HTTP supplementaire indiquant qu'un message d'erreur doit etre affiche. 

• default-target-url : precise FURL vers laquelle l'utilisateur est redirige si 1'authentification a 
reussi. Cette URL est appelee si la page de login etait la premiere page visitee par l'utilisateur. 
Si l'utilisateur a ete redirige vers le formulaire de login suite a une tentative d'acces a une page 
protegee, c'est cette page protegee qui est affichee apres une authentification reussie. 

• login-processing-url : precise l'URL sur laquelle Spring Security attend les parametres 
d'authentification. Par defaut, cette URL est j_spring_security_check. 

Deconnexion 

Spring Security peut positionner un filtre de servlet qui va deconnecter l'utilisateur (lire 
« vider le contexte de securite ») quand son URL va etre appelee. Ce filtre est positionne de la 
maniere suivante : 

<http> 
(...) 

<logout /> 
</http> 

Par defaut, l'URL de deconnexion est j_spring_security_logout. Les pages de l'application 
peuvent done contenir un lien vers cette URL afin que l'utilisateur puisse se deconnecter. 
La balise 1 ogout dispose d'un ensemble de parametres de configuration : 

<http> 
(...) 
<1 ogout 
inval idate-session="true" 
1 ogout- success -url="/l ogoutSuccessful .htm" 
1 ogout -url="/j_tudu_l ogout" /> 
</http> 

Voici la description de ces parametres : 

• invalidate-session : la session HTTP est invalidee lors de la deconnexion de l'utilisateur. 
La valeur par defaut est true, ce qui est generalement le comportement attendu. 

• logout-success-url : URL vers laquelle l'utilisateur est redirige apres la deconnexion. 

• logout-url : URL de deconnexion (par - defaut j_spring_security_logout). 
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Authentification automatique 

Un besoin couramment exprime est 1' authentification automatique pour une periode de temps 
donnee. L' absence de cette fonctionnalite frustre souvent les utilisateurs, qui tendent a ne pas 
revenir sur un site. 

Spring Security fournit en standard deux mecanismes stockant les donnees d' identification de 
l'utilisateur (cookie ou base de donnees), ce qui permet de reauthentifier automatiquement ce 
dernier a chaque nouvelle visite. 

La presence d'un UserDetai 1 sServi ce dans la configuration Spring Security est une condition 
sine qua none pour que F authentification automatique fonctionne. 

Le support de F authentification automatique se parametre de la maniere suivante : 

<http> 
(...) 

<remember-me /> 
</http> 

Par defaut, F authentification automatique utilise un cookie crypte envoye au navigateur de 
l'utilisateur. Pour que cela fonctionne, il faut envoyer un parametre HTTP supplemental a 
FURL d' authentification : „spri ng^securi ty_remember_ne. Ce parametre est automatiquement 
ajoute sous forme d'une case a cocher dans le formulaire genere par f orm- 1 ogi n. 

L authentification par cookie crypte n'est cependant pas totalement fiable, car une personne 
malveillante peut intercepter le cookie et le reutiliser par la suite. 

Spring Security propose un autre mecanisme d' authentification automatique fonde sur la 
persistance en base de donnees du jeton d' authentification. Ce systeme est globalement plus 
fiable car le cookie change a chaque connexion. 

Pour activer le systeme de cookie avec jeton persistant, il faut ajouter une reference a une 
DataSource a la balise remember-me : 

<http> 
(...) 

<remember-me data-source-ref-"dataSource" /> 

</http> 

L'utilisation de cette solution necessite la creation d'une table dans la base de donnees : 
create table persi stent_l ogi ns 

(username varchar(64) not null, series varchar(64) primary key, 
token varchar(64) not null, last„used timestamp not null); 

Le service d' authentification automatique peut etre finement parametre afin d'obtenir une 
solution tres securisee. Nous vous invitons a consulter la documentation de reference de 
Spring Security pour plus d'informations. 
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Connexion anonyme 

Spring Security permet de positionner un contexte de securite par defaut. Ainsi, tout utilisa- 
teur, authentifle ou non, pouiTa disposer d'un identifiant et d'un role. Cette fonctionnalite 
permet de gerer de facon homogene la securite d'une application, en supposant que tous les 
utilisateurs connectes disposent au moins d'une identite (meme anonyme) et d'un role. 

Le service de connexion anonyme se positionne de la maniere suivante : 

<http> 
(...) 

<anonymous /> 
</http> 

En positionnant ce service, le contexte de securite ne sera done jamais nul et pourra etre 
consulte a des fins d'autorisation ou de journalisation. La balise anonymous dispose notamment 
de deux parametres : 

<http> 
(...) 

<anonymous username="guest" granted-authority="ROLE_GUEST" /> 
</http> 

Voici la description de ces deux parametres : 

• username : nom de l'utilisateur a positionner pour la connexion anonyme. Par defaut, Spring 
Security utilise anonymousUser. 

• granted-authority : role positionne. Par defaut, Spring Security utilise R0LE_AN0NYM0US. 
Limitation des connexions simultanees 

Spring Security permet de limiter le nombre de connexions simultanees avec un meme identi- 
fiant. Pour cela, il faut commencer par ajouter un element dans le fichier web.xml : 

<1 istener> 

<1 i stener-cl ass> 

org.springframework.security.ui .session.HttpSessionEventPubl is her 
</l istener-class> 
</l i stener> 

Cela permet a Spring Security de suivre revolution des sessions HTTP de 1' application. II faut 
ensuite positionner le service dans la configuration de Spring Security : 

<http> 
(...) 

<concurrent-session-control max-sessions="l" /> 
</http> 

La valeur de l'attribut max-sessions indique le nombre maximal de connexions simultanees 
pour un meme identifiant. Dans notre exemple, la deuxieme connexion avec un meme identi- 
fiant provoque l'invalidation de la premiere session. Si cela n'est pas le comportement desire, 



Spring Security 

Chapitre 14 



il est possible d'empecher la seconde connexion en utilisant le parametre exception-if- 
maximum-exceeded : 

<http> 
(...) 

<concur rent -session -control 
max-sessions="l" exception-if -maximum-exceeded="true" /> 

</http> 

Lors de la tentative d'une deuxieme connexion avec un identifiant deja connecte, l'utilisateur 
sera redirige vers la page d'authentification. 

Securisation de I'invocation des methodes 

II existe des besoins trop complexes pour etre geres via une securisation d'URL. Imaginons, 
par exemple, une application de vente de produits sur Internet. Les utilisateurs finals de 
1' application n'ont aucun droit en ecriture sur le catalogue produit. 

Nous voudrions etre certains qu'un utilisateur ne puisse jamais acceder a une methode de mise 
a jour d'un produit. Or, de maniere classique, il n'est pas possible de repondre a ce besoin. 
Spring Security permet, grace a la programmation orientee aspect, d'intercepter les appels sur 
des Beans Spring. 

La securisation de I'invocation des methodes peut etre configured de differentes manieres 
avec Spring Security : 

• en apposant des annotations sur les classes ou les methodes a proteger ; 

• globalement, en definissant des coupes (pointcuts) avec la syntaxe AspectJ ; 

• localement, dans la declaration d'un Bean. 

Nous allons voir comment securiser les appels des methodes createUser et findUser de la 
classe UserManagerlmpl dans Tudu Lists avec chacune des configurations supportees par 
Spring Security. La methode createUser sera accessible seulement au role ROLE_ADMIN et la 
methode findUser sera accessible aux roles ROLEJJSER et ROLE_ADMIN. 

La securisation des methodes s'appuyant sur le framework de programmation orientee aspect 
de Spring, elle n'a d'effet que sur des Beans geres par Spring (c'est-a-dire declares dans le 
contexte Spring). 

Securiser avec des annotations 

II est possible avec Spring Security de securiser l'appel de methodes en posant des annota- 
tions soit au niveau de la classe soit au niveau de la methode. Les annotations supportees sont 
celles concernant la securite dans la JSR-250 (Commons Annotations for the Java Platform) et 
une annotation specifique Spring Security, ©Secured. 

Voici comment securiser la classe UserManagerlmpl avec l'annotation @Rol esAl 1 owed de la 
JSR-250 : 



import j a vax. annotation. security. Roles All owed; 
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(...) 

public class UserManagerlmpl implements UserManager { 



@Rol es Al 1 owed ( " R0LE_ADM IN" ) 

public void createUser(User user) 

throws UserAl readyExistsException { 
(...) 

) 



@Rol esAl 1 owed( { "ROLE_ADMIN" , "R0LE_USER" } ) 
public User findUser(String login) { 
(...) 

} 

(...) 

} 

Pour activer la detection de cette annotation par Spring Security, il faut utiliser la balise 
global -method-security avec l'attribut jsr250-annotations : 

<global -method-security jsr250-annotations="enabled" /> 

Grace a cette configuration, Spring Security detecte la presence de l'annotation @Rol esAl 1 owed 
sur des Beans et se fonde sur le contexte de securite pour valider ou non l'acces. 

II est aussi possible d'utiliser l'annotation ©Secured, qui est propre a Spring Security et qui 
fonctionne d'une maniere similaire : 

(...) 

import org. springframework. security. annotation. Secured; 
(...) 

public class UserManagerlmpl implements UserManager { 

@Secured( "ROLE_ADMIN" ) 

public void createUser(User user) 

throws UserAl readyExistsException { 
(...) 

} 

@Secured({"ROLE_ADMIN\ n ROLEJJSER"}) 
public User findUser(String login) { 
(...) 

} 

(...) 

} 
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L' activation de la detection de Fannotation ©Secured se fait de la maniere suivante : 

<global -method-security secured-annotations="enabled" /> 

Les deux types d' annotations peuvent etre utilises conjointement, en positionnant les deux 
attributs dans la configuration (secured-annotations et jsr250-annotations). Meme si c'est 
possible techniquement, il est preferable d'utiliser, pour des raisons d'homogeneite, un seul 
type d' annotation pour une meme application. 

Le choix du type d' annotation (JSR-250 ou ©Secured) est affaire de gout. Si Ton mise plutot sur 
les standards et que Ton utilise d'autres annotations de la JSR-250 (notamment celles liees au 
cycle de vie des Beans), il est preferable d'utiliser @Rol esAl 1 owed. Si Ton veut eviter une depen- 
dance supplementaire et privilegier la simplicite, le choix se porte alors plutot sur ©Secured. 

Securiser un ensemble de Beans 

Spring Security permet de securiser les methodes sur un ensemble de Beans via la definition 
de coupes utilisant la syntaxe AspectJ. La securisation des methodes devient des lors forte - 
ment similaire a la declaration des transactions utilisant le schema XML correspondant. 

La securisation passe par l'utilisation de la balise global -method-security avec des balises 
protect-pointcut pour chacune des securisations. Voici comment securiser le UserManager de 
Tudu Lists : 

<global -method-security> 
<protect-pointcut 

expression="execution(* tudu. service. impl . UserManagerlmpl .createLlser( . . ) )" 
access="ROLE_ADMIN" /> 
<protect-pointcut 

exp ression="executi on (*tudu. service. impl . UserManagerlmpl . f indLlser( . . ) ) " 
access="ROLE_ADMIN,ROLE_USER" /> 
</global -method-security> 

L'attribut expression contient la definition de la coupe au format Aspec tJ et l'attribut access 
les attributs d'acces (generalement une liste de roles). 

L'utilisation de la balise protect-poincut permet une securisation non intrusive et particulie- 
rement souple, grace a la puissance de la syntaxe AspectJ. 

Securiser un Bean 

La declaration d'un Bean Spring peut etre completee par l'ajout de balises Spring Security 
definissant la securisation des methodes de ce Bean. II faut alors utiliser, au sein de la balise 
de declaration bean, la balise intercept-methods, avec des balises protect imbriquees : 

<beans:bean id="userManager" 

cl as s=" tudu. servi ce. impl . UserManagerlmpl "> 
<intercept-methods> 

<protect method="createUser" access="ROLE_ADMIN" /> 
<protect method="findUser" access="ROLE_ADMIN,ROLE_USER" /> 
</i ntercept -met hods > 
</beans : bean> 
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L'attribut method de protect permet d'indiquer une ou plusieurs methodes (avec l'utilisation 
du caractere *). Elle n'utilise pas la syntaxe AspectJ. L'attribut access deflnit les attributs 
d'acces, generalement des roles. 

Preconisations 

Dans Spring Security, il existe trois manieres differentes de securiser Fappel de methodes : 

• Methode par annotations. Son merite est d'etre tres simple et de permettre ainsi de se 
concentrer sur les methodes d'une classe. Elle est en revanche intrusive et decentralisee. 

• Methode globale XML. Tres simple elle aussi, c'est certainement la plus puissante, grace a 
la syntaxe AspectJ. Elle est non intrusive, car totalement declarative, permettant ainsi de 
rendre transverse la problematique de securisation des methodes. Elle necessite cependant 
la connaissance de la syntaxe AspectJ. 

• Methode de securisation locale a un Bean. Plus discutable, elle mele les schemas XML et 
s'avere intrusive dans la configuration. Elle n'est done a utiliser que pour des applications 
de petite taille aux problematiques de securite locales. 



Le systeme de decision d'autorisation 

Quand un utilisateur authentifie tente d'acceder a une ressource protegee (une URL ou une 
methode de Bean), Spring Security effectue des verifications pour autoriser ou non l'acces. 
L'objet effectuant ces verifications est 1'AccessDecisionManager. 

Spring Security propose trois implementations d'AccessDecisionManager, fondees sur un 
systeme de votants (voters). Un AccessDeci si onManager se voit attribuer un ensemble de votants, 
qui donnent chacun leur avis pour autoriser un acces ou pas. L AccessDeci si onManager prend 
ensuite une decision en fonction de l'avis de chacun des votants. 

Les implementations de AccessDeci si onManager sont les suivantes : 

• Af f i rmati veBased : autorise l'acces si au moins un votant donne un avis positif. 

• ConsensusBased : autorise Faeces si la majorite des votants donne un avis positif (Spring 
Security n'utilise pas la la definition stricto sensu d'un consensus). 

• UnanimousBased : autorise Faeces si Funanimite des votants donne un avis positif. 

II est possible de positionner une liste de votants pour chacun de ces AccessDeci si onManagers. 
Un votant doit implementer Finterface AccessDeci si onVoter. Les resultats possibles d'un vote 
sont represented par des constantes de Finterface AccessDecisionVoter : ACCESS_GRANTED, 
ACCESS_DENI ED et ACCESS_ABSTAIN. 

Nous verrons par la suite qu'un votant peut choisir de voter ou non, selon le contexte de secu- 
rite et les attributs d'acces. En effet, un votant n'est pas toujours « competent » dans une decision 
d'acces. 

Par defaut, Spring Security positionne un gestionnaire d'acces Affi rmati veBased avec deux 
votants : 

• Rol eVoter : vote pour les decisions fondees sur les roles de Futilisateur. II ne vote done que 
pour les decisions d'acces commencant par R0LE_. C'est notamment pour cela que Spring 
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Security prefixe systematiquement les roles d'un utilisateur. Le Rol eVoter donnera un vote 
positif si l'utilisateur a au moins un role parmi les roles requis. 

• Authenti catedVoter : vote pour un acces fonde sur le niveau d'authentification de l'utilisa- 
teur. Ce votant votera pour les attributs d'acces IS_AUTHENTICATED_FULLY, IS_ 
AUTHENTI CATED_REMEMBERED et IS_AUTHENTICATED_ANONYMOUSLY. II donnera un vote positif si le 
niveau d'authentification de l'utilisateur est superieur a celui indique par l'attribut d'acces. 
Les niveaux sont, du plus eleve au plus bas, fully, remembered et anonymously. 

L'AccessDecisionManager positionne par Spring Security est suffisant dans la plupart des cas, 
mais il peut s'averer necessaire de parameter plus finement les decisions d'autorisation. Nous 
allons voir comment positionner notre propre AccessDecisionManager, avec notamment un 
votant que nous allons implemented Ce votant se fondera sur le nom de l'utilisateur pour 
donner son aval quant a la decision d'acces. 

Voici une implementation possible de ce votant : 
package tudu. security. voters; 

import org. spring-framework, security .Authentication; 

import org.springf ramework. security .ConfigAttribute; 

import org.springf ramework. security .ConfigAttri buteDefiniti on; 

import org.springf ramework. security .vote. Access Deci si onVoter; 

public class UserVoter implements AccessDecisionVoter { 

private static final String USER_PREFIX = "USER_";<— Q 

public boolean supports(ConfigAttribute attribute) { 
return attribute. getAttribute( ) != null 

&& attribute. getAttribute().startsWith(USER_PREFIX);^0 

} 

public boolean supports(Cl ass clazz) { 
return true;<— Q 

} 

public int vote(Authentication authentication, Object object, 
ConfigAttributeDefinition config) { 
String username = authentication. getName( ) ; 
int result = ACCESS_ABSTAIN ; 

for(0bject element : config. getConfigAttributes( ) ) { 
ConfigAttribute attribute = (ConfigAttribute) element; 
if (this. supports (attribute) ) {<— Q 
result = ACCESS_DENIED; 
if (attribute. getAttribute( ) .substring( 
USER_PREFIX.length(), 
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attribute.getAttribute( ) . 1 engtht ) ) 
.equalsIgnoreCase(username)) {<— Q 
return ACCESS_GRANTED; 

} 

} 

} 

return result; 

} 

} 

II s'agit la d'une implementation simpliste, mais suffisante pour illustrer le principe de deve- 
loppement d'un votant. Nous declarons en premier lieu le type d'attributs d'acces que le 
votant va accepter, sous la forme d'une constante (Q). La premiere methode supports est 
appelee par le gestionnaire d'acces pour savoir si le votant peut etre consulte. Notre votant 
s'implique dans le vote seulement si l'attribut d'acces commence par USER_ (Q). 

La deuxieme methode supports n'est pas utile dans notre cas. Elle sert pour les votants 
travaillant sur l'autorisation d'un objet, notamment pour les listes de controle d'acces. Notre 
votant retourne done systematiquement true (©). Dans la methode vote, le votant parcourt 
les attributs d'acces de la ressource et interroge sa methode supports pour savoir s'il peut 
l'evaluer (Q). Enfin, le votant verifie si l'attribut d'acces se termine par le nom de l'utilisateur 
(©). La verification n'est pas sensible a la casse. 

Une fois le votant defini, il faut le positionner dans la liste des votants. II faut done definir 
explicitement 1'AccessDecisionManager en positionnant ces votants : 

<beans :bean id="accessDecisionManager" 

class="org.springf ramework. security .vote. Affi rmativeBased"> 
<beans : property name="deci sionVoters"> 
<beans:list> 
<beans rbean 

cl ass-" org. springf ramework. security .vote. RoleVoter" /> 
<beans:bean 

cl a ss=" org. springf ramework. security .vote. Authenticated Voter" /> 
<beans:bean class="tudu. security. voters. UserVoter" /> 

</beans : 1 i st> 
</beans:property> 
</beans : bean> 

Nous reprenons ici la configuration par defaut en lui ajoutant notre votant. II faut ensuite indi- 
quer a Spring Security d'utiliser ce gestionnaire d'acces. Pour une configuration d' application 
Web: 

<http access -deci si on -manager -ref-" access DecisionManager" > 

<intercept-url pattern="/admin/**" access="USER_ACOGOLUEGNES" /> 



(...) 

</http> 
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ou pour la securisation d'appel de methodes : 
<global -method-security 

acces s-deci si on -manage r - ref=" access Deci si onManager"> 

<protect-pointcut express ion="executi on ( 

* tudu. service. impl .UserServicelmpl .createUser( . . ))" 
access="USER_ACOGOLUEGNES" /> 
</gl obal -method -security> 

Si le systeme de decision d' acces de Spring Security est totalement transparent (dans sa confi- 
guration par defaut), il est cependant possible de le parameter. Les implementations 
d'AccessDecisionManager et d'AccessDecisionVoter permettent d'obtenir des configurations 
tres sophistiquees tout en laissant la possibilite d'implementer sa propre logique de vote. 



Securisation des vues 

Nous avons vu jusqu'ici comment effectuer une securisation en aval, c'est-a-dire, pour une 
application Web, une fois qu'une URL a ete demandee. Si cette solution permet d'eviter que 
des utilisateurs malicieux tentent d'acceder directement a des URL protegees, il s'agit d'une 
pratique frustrante pour un utilisateur cliquant sur un lien et se voyant refuser 1' acces. Pour 
eviter ce genre d' experiences malheureuses, il est de coutume d' effectuer des verifications en 
amont, c'est-a-dire de ne pas generer des liens qui ne sont pas permis a l'utilisateur. II est aussi 
frequent que certaines informations necessitent d'etre cachees. Le code HTML correspondant 
n'est alors pas genere non plus. 

Spring Security propose un ensemble de balises JSP permettant d'acceder au contexte de 
securite. II est alors possible d'effectuer des tests portant sur les roles de l'utilisateur ou de 
recuperer des informations sur l'utilisateur. 

Voici un exemple d' utilisation des balises JSP les plus courantes de Spring Security : 

<%@ tagl i b prefix="c" uri="http://java. sun.com/jsp/jstl/core" %> 

<%@ tagl i b prefix=" security" uri="http://www. springframework.org/security/tags" %><— Q 

<h2>Bienvenue <security:authentication property-"principal .username" /X/h2><— Q 

<security:authentication property="authorities" var="authorities" /><— Q 

<ul> 

<c:forEach i tems=" $ {authori ti es} " var="authority"><— Q 

<li>${authority}</li> 
</c:forEach> 
</ul> 

<security: authorize ifAHGranted="ROLE_ADMIN,ROLE_USER"><-0 
a la fois admin ET utilisateur. 
</security: authori ze> 

<security: authorize i f Any Gran ted=" ROLE_ADMIN , R0LE_USER"><— © 
pour les admins OU les utilisateurs. 
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</secun'ty: authorize) 

<security: authorize if NotGranted="ROLE_ADMIN, R0LE_USER"><— 0 
ni pour les admins, ni pour les uti 1 i sateurs . 
</security:authorize> 

II faut dans un premier temps inclure la bibliotheque de balises JSP de Spring Security (Qi). 
La balise authentication permet d'acceder a des proprietes de l'objet Authentication. II est, 
par exemple, possible d'afficher l'identinant de Futilisateur (Q) ou de recuperer l'ensemble 
de ces roles dans une variable (Q) puis d'afficher chacun d'entre eux (Q). 

La balise authorize permet d'afficher de facon conditionnelle son contenu. La verification se 
fait sur les roles de Futilisateur. II existe trois attributs qui acceptent chacun une liste de roles 
separes par des virgules. Avec l'attribut if All Granted, Futilisateur doit posseder l'ensemble 
des roles pour que le contenu soit evalue (©). Avec l'attribut i f AnyGranted, il suffit que Futili- 
sateur possede au moins un des roles de la liste (Q). Avec l'attribut ifNotGranted, le contenu 
ne sera evalue que si Futilisateur n'a aucun des roles de la liste (Q). 

Mise en cache des donnees utilisateur 

Les implementations JDBC et LDAP de UserDetailsService de Spring Security peuvent 
s'interfacer avec une solution de cache arm d'optimiser les acces au depot de donnees. Spring 
Security propose un support natif pour la solution de cache Ehcache. 

Voici comment positionner un cache sur un UserDetai 1 sServi ce JDBC : 
<authentication-provider> 

<jdbc-user-service cache-ref="userCache" (...) /><— Q 
</authentication-provider> 

<beans:bean id="userCache" 

cl ass=" org. springframework.security.providers.dao. cache. EhCacheBasedUserCache"><— © 

<beans rproperty name="cache" ref="userEhCache" /><— Q 
</beans : bean> 

<beans:bean id="userEhCache" 

cl as s=" org. springf ramework. cache. ehcache. EhCacheFactoryBean"> 
<beans rproperty name="cacheManager" ref="cacheManager" /><— Q 
<beans rproperty name="cacheName" val ue="UserCache" /><— Q 

</beans : bean> 

<beans:bean id="cacheManager" class=" 

org. springf ramework. cache. ehcache. EhCacheManagerFactoryBean"> 
<beans rproperty name="conf i gLocati on" 

val ue="cl a sspath: tudu/security /ehcache. xml " /><— Q 
</beans : bean> 

Le positionnement du cache se fait avec l'attribut cache-ref de la balise jdbc-user-service 
(Q) — il existe le meme attribut pour 1 dap-user-servi ce. Cet attribut fait reference au Bean 
userCache que nous definissons au repere Q. Ce Bean represente le pont entre Spring Security 
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et 1' implementation de cache. Pour Ehcache, il faut utiliser la classe EhCacheBasedUserCache et 
lui injecter un Bean representant une region du cache (Q). 

Spring supportant Ehcache, il dispose d'une fabrique pour les regions de cache. II faut passer 
a cette fabrique le gestionnaire de cache (Q) et indiquer le nom de la region (©). Le gestion- 
naire de cache gere un ensemble de regions de cache et se configure a partir d'un fichier XML 
(©)■ La encore, Spring propose un support pour la creation du gestionnaire de cache. 

Le fichier de configuration de Ehcache a l'apparence suivante : 
<ehcache> 

<diskStore path="java.io.tmpdir" /> 

<def aul tCache 

maxEl ementsInMemory="1000" 
eternal-"fal se" 
timeToIdl eSeconds="120" 
timeToLi veSeconds="120" 
overf lowToDi sk="fal se" 

/> 

<cache name="UserCache" 

maxEl ementsInMemory="1000" 
eternal-"fal se" 
overf 1 owToDi sk="true" 
timeToIdl eSeconds="300" 
timeToLi veSeconds=" 1800" 

/> 

</ehcache> 

La region de cache que nous utilisons pour les informations utilisateur recuperees par Spring 
Security est definie a la deuxieme balise cache (elle porte le nom UserCache que nous avons 
precise dans le fichier Spring). Ainsi, le cache contient-il au maximum mille objets 
UserDetails en memoire, l'excedant etant stocke en memoire. Si un objet du cache n'est pas 
utilise pendant cinq minutes (300 secondes), il est supprime du cache. Dans tous les cas, tout 
objet UserDetai 1 s est supprime au bout de trente minutes (1 800 secondes). 

La configuration d'un cache pour un UserDetai IsService est done relativement simple. Elle 
permettra d'economiser des requetes vers le depot de donnees. Elle s'averera utile dans les cas 
ou les donnees utilisateur changent tres peu (lecture seule) et ou les utilisateurs ont des 
sessions tres courtes et s'authentifient souvent. 

Lutilisation d'un cache a cependant moins d'interet pour les cas suivants : 

• Les sessions utilisateur sont longues (les utilisateurs s'authentifient une seule fois pour une 
periode relativement longue). En effet, Spring Security stocke alors les informations utili- 
sateur dans la session HTTP et n'effectue qu'une requete vers le depot de donnees. 

• Implementation specifique de UserDetai IsService dans laquelle un systeme externe (Hiber- 
nate, JPA, etc.) s'occupe de la recuperation des informations et gere son propre cache. 
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Securisation des objets de domaine 

Spring Security propose une securite ail niveau des instances des objets de domaine. Nous 
avons justifie ce besoin en debut de chapitre. Si nous prenons l'exemple de Tudu Lists, nous 
avons jusqu'a present securise des URL ou des methodes, mais nous n' avons pas securise les 
todos eux-memes. Nous pouvons done restreindre la suppression d'un todo, mais n'avons pas 
verifie si une personne supprimant un todo est bien le possesseur de ce todo. Or seul le possesseur 
d'un todo devrait avoir le droit de Feffacer. 

II est possible d'implementer ce genre de verifications avec des instructions specifiques dans 
le code : 

public Todo findTodo( final String todold) { 
Todo todo = todoDAO. getTodo(todoId) ; 
TodoList todoList = todo.getTodoList( ) ; 
User user = userManager.getCurrentllser( ) ; 
if ( ! user.getTodoLi sts( ) .contains(todoLi st) ) { 
throw new PermissionDeniedException( 

"Permission denied to access this Todo."); 

} 

return todo; 

} 

Cette solution est tout a fait legitime, car la securite des objets de domaine est souvent une 
problematique specifique a une application, et une solution generique, meme souple, n'est pas 
toujours adaptee. 

Cependant, pour des cas relativement classiques, Spring Security propose un mecanisme puis- 
sant de liste de controle d'acces, ou ACL (Access Control List). Chaque objet de domaine 
dispose ainsi d' informations concernant les differents droits qui lui sont associes (droit d'effacer, 
de mettre a jour, etc.). 

Ces informations sont stockees en base de donnees, et Spring Security fournit des classes pour 
les mettre a jour et les consulter. Des systemes de securisation fondes sur le systeme de 
vote de Spring Security sont aussi disponibles. Les listes de controle d'acces de Spring 
Security s'integrent done tres bien avec le reste du framework, formant un systeme homo- 
gene et coherent. 

Nous allons detailler le fonctionnement des listes de controles d'acces de Spring Security. II 
s'agit d'un sujet avance, necessitant une bonne comprehension des autres composantes du 
framework, notamment la securisation des methodes et le systeme de gestion d'acces 
(AccessDecisionManager). II est important de signaler qu' a l'heure ou sont ecrites ces lignes, le 
support des listes de controle d'acces de Spring Security n'est pas encore portable sur toutes 
les bases de donnees. Nous illustrerons notre propos avec la base de donnees Java HSQLDB. 

Le systeme de liste de controle d'acces de Spring associe a l'identite d'un objet de domaine un 
ensemble d'entrees de controle d'acces, ou ACE (Access Control Entries). 

Une entree de controle d'acces est composee de deux parties : 

• Un ensemble de permissions : il s'agit des actions possibles sur l'objet (lecture, modifica- 
tion, suppression, etc.). Dans Spring Security, les permissions sont representees sous la 
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forme de masques de bit (un nombre pour faire simple). La classe BasePermission definit 
cinq permissions sous forme de constantes (READ, WRITE, CREATE, DELETE et ADMINISTRATION). 
II est possible d'etendre ces permissions avec tout le panel de valeurs disponibles. 

• Uidentite de securite: representee par 1' interface Sid. II s'agit de l'identite sur laquelle 
portent les permissions. Spring Security propose une implementation fondee sur un utilisateur 
(Principal Sid) et sur un role (GrantedAuthoritySid). 

Definition du service de gestion des ACL 

Spring Security fournit un support pour le stockage des listes de controle d'acces dans une 
base de donnees. Ce stockage necessite la creation de plusieurs tables. 

Voici le script de creation de ces tables pour la base de donnees HSQLDB (ce script peut etre 
trouve dans les applications exemples de Spring Security) : 

CREATE TABLE AC L_S I D ( 

ID BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY, 

PRINCIPAL BOOLEAN NOT NULL, 

SID VARCHAR_IGN0RECASE(100) NOT NULL, 

CONSTRAINT UNIQUE_UK_1 UNIQUEC SID , PRINCIPAL) 

); 

CREATE TABLE ACL_CLASS( 

ID BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY, 
CLASS VARCHAR_IGN0RECASE(100) NOT NULL, 
CONSTRAINT UNIQUE_UK_2 UNIQUEC CLASS ) 

); 

CREATE TABLE ACL_OBJECT_IDENTITY( 

ID BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY, 
OBJECT_ID_CLASS BIGINT NOT NULL, 
OBJECT_ID_IDENTITY BIGINT NOT NULL, 
PARENTJBJECT BIGINT, 
0WNER_SID BIGINT, 

ENTRI ES_I NHERITING BOOLEAN NOT NULL, 
CONSTRAINT UNIQUE_UK_3 

UNIQUE(OBJECT_ID_CLASS,OBJECT_ID_IDENTITY), 
CONSTRAINT FOREI GN_FK_1 FOREIGN KEY( PARENT_OBJECT) 

REFERENCES AC L_0BJ ECT_I DENTI TY ( ID) , 
CONSTRAINT FOREI GN_FK_2 FOREIGN KEY ( OBJ ECT_ID_C LASS) 

REFERENCES AC L_C LASS ( I D ) , 
CONSTRAINT FOREI GN_FK_3 FOREIGN KEY ( OWN ER_S I D ) 

REFERENCES ACL_SID( ID) 

); 

CREATE TABLE ACL_ENTRY( 

ID BIGINT GENERATED BY DEFAULT AS IDENTITY NOT NULL PRIMARY KEY, 
ACL_OBJECT_IDENTITY BIGINT NOT NULL, 
ACEJRDER INT NOT NULL, 
SID BIGINT NOT NULL, 
MASK INTEGER NOT NULL. 
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GRANTING BOOLEAN NOT NULL, 
AUDIT_SUCCESS BOOLEAN NOT NULL, 
AUDIT_FAI LURE BOOLEAN NOT NULL, 

CONSTRAINT UNIQUE_UK_4 UNIQUEC AC L_OBJ ECT_I DENTI TY , ACEJRDER) , 
CONSTRAINT F0REIGN_FK_4 FOREIGN KEY ( AC L_OB J ECT_I DENT I TY ) 

REFERENCES ACLJBJECT_IDENTITY( ID) , 
CONSTRAINT F0REIGN_FK_5 FOREIGN KEY(SID) REFERENCES AC L_S I D ( I D ) 

); 

L'interface pour la gestion des listes de controle d'acces est Mutabl eAcl Servi ce. Elle permet a 
la fois de consulter des listes et de les modifier. C'est un objet implementant cette interface qui 
est manipule par le code applicatif pour travailler les listes de controles d'acces. 

Spring Security fournit une implementation, JdbcMutabl eAcl Service, utilisant un 
JdbcTempl ate en interne. Le schema XML de Spring Security ne proposant pas de support 
pour la definition d'un JdbcMutabl eAcl Servi ce, nous allons utiliser le schema de base de crea- 
tion de Beans de base (beans). II est judicieux d'effectuer la configuration des services de 
listes de controle d'acces dans un fichier dedie, par exemple security-acl.xml. 

Voici la definition d'un JdbcMutabl eAcl Service : 
<bean id="lookupStrategy"<— Q 

cl ass="org.springf ramework. security .acls. jdbc.BasicLookupStrategy"> 
<constructor-arg ref="dataSource" /> 
<constructor-arg ref="acl Cache" /> 
<constructor-arg> 
<bean 

class-"org.springf ramework. security. acls. domain. Acl Author izationStrategylmpl "><— Q 
<constructor-arg> 
<list> 

<ref local="roleAdmin" /> 
<ref local="roleAdmin" /> 
<ref local-"roleAdmin" /> 
</list> 
</constructor-arg> 
</bean> 
</constructor-arg> 
<constructor-arg> 
<bean 

cl as s-" org. spr i ngf ramewo r k. secu rity. a els. domain. Cons oleAud it Logger" 

/> 

</constructor-arg> 
</bean> 

<bean id="roleAdmin"<— Q 

cl as s=" org. spr i ngf ramewo rk. security .GrantedAuthoritylmpl "> 
<constructor-arg val ue="ROLE_ADMIN" /> 
</bean> 

<bean i d="acl Servi ce"<— Q 

cl a s s=" org. spr i ngf ramework. secu rity. acl s.jdbc. JdbcMutabl eAcl Servi ce"> 
<constructor-arg ref="dataSource" /> 
<constructor-arg ref-"l ookupStrategy" /> 
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<constructor-arg ref="acl Cache" /> 
</bean> 

<bean id="aclCache"<— 0 

cl a ss=" org. springf ramework. security. a els. jdbc.EhCacheBasedAcl Cache "> 
<constructor-arg> 
<bean 

cl as s-" org. springf ramework. cache. ehcache. EhCacheFactoryBean"> 

<property name="cacheManager"> 

<bean 

class=" org. springf ramework. cache. ehcache. EhCacheManager Factory Bean" 
/> 

</property> 

<property name="cacheName" val ue="acl Cache" /> 
</bean> 
</constructor-arg> 
</bean> 

L'objet final est acl Service (0), qui est de la classe JdbcMutabl eAcl Service. II necessite une 
DataSource pour fonctionner ainsi qu'un cache. Le cache est defini au repere 0 (nous revien- 
drons sur sa configuration par la suite). Le Bean acl Service necessite une LookupStrategy 
pour fonctionner. C'est cette dependance qui va effectuer une grande partie des requetes vers 
la base de donnees. La LookupStrategy est definie au repere 0. 

Nous utilisons F implementation BasicLookupStrategy, qui tente de trouver un compromis 
entre perfomiances et portabilite. Si les performances des listes de controle d'acces ne sont pas 
satisfaisantes pour votre application, il est possible d'ecrire votre propre implementation de 
LookupStrategy, adaptee a vos besoins et tirant au mieux parti de la base de donnees sous-jacente. 
Une Basi cLookupStrategy necessite aussi une DataSource et un cache pour fonctionner. 

La troisieme dependance determine la strategie d'autorisation de modification des listes de 
controle d'acces (0). Nous utilisons une implementation fondee sur la notion de roles, a 
laquelle nous passons une reference au role ROLE_ADMIN (Bean defini au repere 0). 

La definition du cache (0) suit le meme principe que la mise en cache des informations utili- 
sateur que nous avons etudiee precedemment. La region de cache que nous utilisons ici est 
acl Cache. 

Utilisation du service de gestion des ACL 

Une fois le service de gestion des listes de controle d'acces defini, il est possible de l'injecter 
dans d'autres Beans (typiquement des DAO) arm de maintenir les listes. 

En voici un exemple d'utilisation dans un DAO : 
@Autowi red 

private MutableAclService mutabl eAcl Servi ce ;<— 0 

public void savedodo todo) { 
em.persist(todo) ; 
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Objectldentity oid = new Objectldentitylmpl ( 

Todo .cl ass ,todo.getId( ) 
);<-0 

MutableAcl acl = mutabl eAcl Servi ce. createAcl (oid) ;<— 0 
acl .insertAce( 

0. BasePermiss ion. ADMINISTRATION, 
new Principal Sid(getUsername( ) ) , 
true 

);<-© 

acl .insertAce( 

1. BasePermiss ion. DELETE, 

new GrantedAuthoritySid("ROLE_ADMIN") , 
true 
);<-0 

mutabl eAcl Service. updateAcl (acl ) ;<— 0 

} 

public void del ete(AclTodo todo) { 

em. remove ( em. find (Acl Todo. cl ass , todo. get Id( ) ) ) ; 

Objectldentity oid = new Objectldentitylmpl ( 
Todo. class, todo. get Id ( ) 

); 

mutabl eAcl Service. del eteAcl (oid, false) ;<— © 

} 

public String getUsernamet ) { 

return SecurityContextHolder.getContextt ) 

.getAuthentication( ) . get Name ( ) ;<— 0 

) 

Le service de gestion est injecte dans le DAO avec de l'autowiring (0). Suite a Finsertion 
d'un todo, une nouvelle liste de controle d'acces est creee. L'identite de l'objet, constitute 
pour Spring Security de sa classe et de son identifiant base de donnees, est creee au repere 0. 
Le service permet de creer l'objet pointant vers la liste (0). 

La premiere entree de controle d'acces est cree au repere 0. Elle donne les droits d' adminis- 
tration a l'utilisateur connecte. Son identite est recuperee grace au contexte de securite (Q). 
Une deuxieme entree est creee au repere 0. Elle donne le droit de supprimer le todo a tout 
utilisateur ayant le role ROLE_ADMIN. La liste de controle d'acces est ensuite persistee (0). Si le 
todo est supprime, il faut egalement supprimer la liste correspondante. C'est ce qui est fait au 
repere 0. 

Les methodes de la classe JdbcMutabl eAcl Servi ce doivent etre appelees dans un contexte tran- 
sactionnel, pour des raisons evidentes de coherence de donnees. JdbcMutabl eAcl Service 
s'integre naturellement avec la gestion des transactions de Spring. 

Nous avons montre un exemple ou les listes de controle d'acces sont maintenues explicite- 
ment. II est aussi possible de rendre cette problematique completement transversale, en 
utilisant de la programmation orientee aspect pour les methodes des DAO. 
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Effectuer des controles d'acces 

II est possible d'utiliser le service de gestion des listes pour verifier les droits d'un utilisateur 
sur un objet. II faut alors manipuler directement F API de Mutabl eAcl Servi ce. 

Spring Security permet d'effectuer ce genre de verification avec une securisation des methodes 
et un votant verifiant les parametres des methodes appelees. Toute operation sur un objet de 
domaine peut alors etre verifiee de facon transverse. Ce modele permet de centraliser la logique 
d'acces lors de la creation de Fobjet, le reste des verifications se faisant de facon declarative. 

Nous allons configurer un controle d'acces sur une methode destinee a supprimer un todo : 

<bean id="acl MessageUpdateVoter" 

cl a ss-"org.springframework. security. vote. Acl Entry Vote r"><— Q 
<constructor-arg ref="aclService" /><— Q 
<constructor-arg val ue="ACL_TODO_DELETE" /><— Q 
<constructor-arg> 

<list> 

<ref 1 ocal="PERMISSION_ADMINISTRATION" /><-© 
<ref local="PERMISSION_DELETE" /> 
</list> 
</constructor-arg> 

<property name="processDomainObjectCl ass" 
value="tudu. domain. model .Todo" /><— Q 
</bean> 

<ut1l constant i d=" P ERMI SSION_ADMI NISTRATION " 

stati c-fi el d="org.springframework. security. acl s. domain. 
BasePermissi on. ADMINISTRATION" /><— © 

<util rconstant id="PERMISSION_DELETE" 
stati c-fi el d="org.springframework. security. acl s. domain. 
BasePermission. DELETE" /> 

<bean id="acl Access Deci si onManager" 

cl a ss-"org. springframework. security .vote.Affirmati veBased"><— Q 
<property name="decisionVoters"> 
<list> 

<bean class="org. springframework. security. vote. RoleVoter" /> 
<ref 1 ocal="acl MessageUpdateVoter" /> 
</list> 
</property> 
</bean> 

<security: global -method -security 
access -deci si on -manager -ref=" acl Access Deci si onManager" 
secured-annotati ons="enabl ed" /><— Q 

Le votant est un Acl EntryVoter (Q). II a besoin du service de gestion des listes de controle 
d'acces pour fonctionner (Q). Le votant ne va participer aux votes que si l'attribut d'acces 
ACL_T0D0JELETE est positionne sur la ressource, en l'occurrence une methode (©). D'auttes 
attributs d'acces, par exemple des roles, peuvent etre presents. II n'y a pas de limite a la coha- 
bitation, et le gestionnaire d'acces effectuera 1' arbitrage entre les differents votants. 
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Les permissions d'acces sont positionnees au repere Q. Elles correspondent aux droits 
d' administration et de suppression. Cela signifie que la personne tentant d'acceder aux metho- 
des protegees devra disposer des droits correspondants sur Fobjet passe en parametre. La 
configuration des permissions fait reference a des Beans correspondant a des constantes (defi- 
nis au repere 0). 

II faut indiquer au votant sur quel type d'objet travailler. C'est ce qui est fait au repere 0. Le 
votant analysera done les objets de la classe correspondante qui sont passes en parametres aux 
methodes protegees. 

Nous parametrons au repere Q le gestionnaire d'acces, avec un votant utilisant les roles et le 
votant que nous venons de definir. Enfin, nous activons la securisation des methodes au 
repere Q, en referencant bien notre gestionnaire d'acces. Les methodes sont ici securisees par 
annotations, mais il serait aussi possible de les securiser au moyen d'une coupe definie par 
une expression Aspect!. 

Nous pouvons proteger la methode effacant un todo a l'aide de l'annotation ©Secured, agre- 
mentee de l'attribut d'acces activant notre votant : 

@Secured( "ACL_T0D0_DELETE" ) 
public void deletedodo todo) { 

em. remove (em. find (Todo. cl ass , todo. get Id ( ) ) ) ; 

Objectldentity oid = new Objectldentitylmpl ( 
Todo .cl ass , todo. get Id ( ) 

); 

mutabl eAcl Service. del eteAcl (oid.f al se) ; 

} 

La suppression d'un todo est des lors protegee. Le votant ne fait pas de controle sur le nom de 
la methode, mais sur l'objet todo qui est passe en parametre. II verifie que l'utilisateur dispose 
bien des permissions d' administration et de suppression sur l'objet en verifiant sa liste de 
controle d'acces. 

Comment le votant recupere-t-il l'identite de securite de notre todo ? Lors de la creation de la 
liste de controle d'acces, nous avons explicitement cree un objet Objectldentity a partir de la 
classe et de l'identifiant du todo. Si le votant connait la classe, il ne peut connaitre l'identifiant 
de l'objet et done retrouver sa liste de controle d'acces. Le votant utilise par defaut la methode 
getld sur l'objet, ce comportement etant defini par la Si dRetrieval Strategy du votant. Cette 
strategie convient a la plupart des cas. 

Verifier les objets renvoyes 

Nous avons vu comment proteger les traitements sur certains objets de fa5on transparente. 
Spring Security permet aussi de securiser les objets de domaines renvoyes par les methodes 
des Beans. Cette securisation peut consister a interdire l'acces a un seul objet de domaine ou 
a filtrer une collection d'objets de domaine afin que l'utilisateur n'obtienne que les objets 
auxquels il a droit. 
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Voici comment positionner les deux types d'intercepteurs effectuant les filtrages : 
<bean id="afterAcl Read" 

class="org.spn'ngframework.security.afterinvocation.Acl EntryAfterInvocationProvider"><— Q 
<sec: custom- after -invocati on -provider /><— Q 
<constructor-arg ref="aclService" /> 
<constructor-arg> 
<list> 

<ref local="PERMISSION_ADMINISTRATION" /><-© 
</list> 
</constructor-arg> 
</bean> 

<bean id-"afterAclCollectionRead" 

cl a ss=" org. sp r i ngf ramework. security. after invocati on. Acl EntryAfter I nvocationCollec 
i on Fi 1 teringProvider"><— Q 

<sec: custom- after- invocati on -provider /> 
<constructor-arg ref="aclService" /> 
<constructor-arg> 
<list> 

<ref local="PERMISSION_ADMINISTRATION" /> 
</list> 
</constructor-arg> 
</bean> 

<ut1l :constant i d=" P ERMI SSION_ADMI NISTRATI ON " 

static-fi el d="org.spri ngf ramework. security. acl s. domain. 
BasePermi ssi on .ADMIN ISTRATION"/><—© 

L'intercepteur effectuant les verifications sur un seul objet de domaine est un 
Acl EntryAfterlnvocationProvider (Q). Pour que cet intercepteur soit active, il faut que sa 
declaration contienne labalise custom-after- invocation-provider du schema XML de Spring 
Security (Q). Les permissions necessaires pour que l'intercepteur laisse l'acces a l'objet 
metier retourne par la methode sont passees au constructeur. Nous ne passons ici que la 
permission d' administration (©), en faisant reference a un Bean defini au repere©. Cet 
intercepteur va generer une exception si une methode retourne un objet pour lequel l'utilisateur 
n'a pas la permission d' administration. 

L'intercepteur retravaillant les collections d'objets de domaine retournees est defini au 
repere Q. Sa configuration suit le meme principe que celle du premier intercepteur. II va 
supprimer quant a lui des collections les objets de domaine pour lesquels l'utilisateur n'a pas 
la permission d' administration. 

Les deux intercepteurs suivent le meme principe que 1' EntryAcl Voter pour recuperer l'identite 
de securite d'un objet (utilisation de la classe et de la methode get Id, possibilite de parame- 
trage de la SidRetrievalStrategy). 

Comme pour F Entry Acl Voter, les deux intercepteurs sont actives si un certain attribut d'acces 
est positionne sur la ressource, c'est-a-dire une methode. Cet attribut est AFTER_ACL_READ pour 
1' EntryAcl Voter et AFTER_ACI__COLLECTION_READ pour l'Acl EntryAf terlnvocati onProvider. 
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Voici comment activer ces deux intercepteurs via des annotations ©Secured : 

@Secured({"ROLE_USER" , "ROLE_ADMIN" , "AFTER_ACL_READ" } ) 
public Todo getdong id) { 

return em.find(Todo.class,id) ; 

} 

@Secured( {"ROLEJSER" , "ROLE_ADMIN" , " AFT E R_AC L_C0 L LECT 1 0 N_READ " } ) 

public Collection<Todo> selectAllO { 

return (Collection<Todo>) em.createQuery( 

"from "+Todo.cl ass .getName( ) ) . get Res ul t List ( ) ; 

} 

Pour la methode get, une exception sera lancee si l'utilisateur n'a pas la permission d'admi- 
nistration sur le todo retourne. Pour la methode sel ectAl 1 , les todos pour lesquels l'utilisateur 
n'a pas les droits d' administration seront supprimes de la collection retournee. 

En resume 

Spring Security propose un support puissant pour les listes de controle d'acces des objets de 
domaine. L'utilisation de ce support necessite cependant une bonne comprehension de la 
plupart des concepts du framework. Pour l'instant, le support natif ne propose pas une porta- 
bilite optimale, mais il est possible de brancher ses propres implementations sur les differents 
points d'extension. 

La possibilite d'utiliser un cache permet de remedier a des problemes de performances dus a la 
forte solicitation de la base de donnees. Cependant, l'utilisation de ce cache doit tenir compte de 
l'utilisation d'un autre cache dans l'application, par exemple par un outil comme Hibernate. 

Pour cet ensemble de raisons, l'outil puissant que constitue le support pour les listes de 
controle d'acces de Spring Security est reserve aux utilisateurs les plus avertis. 



Conclusion 

Spring Security propose un modele de securite eprouve, stable et performant, a meme de 
repondre a 1' ensemble des attentes : securisation des URL, des methodes et des instances 
d'objets, fourniture de nombreux filtres, par exemple, permettant 1'authentification par formu- 
laire, 1'authentification automatique par cookie, etc. 

Pour des besoins de securite basiques, Spring Security propose des fonctionnalites faciles a 
mettre en ceuvre, grace notamment a son schema XML dedie. Pour des besoins plus avances, 
il est necessaire d'apprehender des mecanismes plus avances du framework. 

Spring Security etant tres peu intrusif, sa configuration est independante de celle des autres 
Beans Spring. C'est la son principal atout. La securite est en effet une notion transversale, qui 
ne doit pas avoir d'impact sur l'application en elle-meme. 
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Un besoin recurrent pour les applications d'entreprises est le traitement automatique de 
grande quantite de donnees, ce qu'on appelle le traitement par lots. Par traitement on attend 
par exemple la lecture de donnees depuis une source (fichier plat, base de donnees, etc.), la 
validation ou la modification de ces donnees puis leur ecriture sous une autre forme. 

D'un point de vue fonctionnel, il peut s'agir de la necessite d' analyser des donnees a des moments 
cles, comme des bilans mensuels ou annuels. L' analyse pouvant impliquer des millions d'enregis- 
trements en base de donnees, avec, de plus, des algorithmes metier complexes et des requetes tres 
couteuses, il n'est souvent pas envisageable d'effectuer les traitements en temps reel, sur le 
systeme de production. Les exports de donnees sont alors reportes a des moments ou le systeme 
est moins sollicite, et leur exploitation peut se faire sur un systeme dedie, coupe de la production. 
On parle generalement de batch pour qualifier ce genre de traitement. 

Les batch, en plus de manipuler enormement de donnees et d'effectuer des traitements 
complexes, s'executent de facon automatique, sans intervention humaine. lis doivent done 
faire preuve d'une robustesse a toute epreuve, mais des erreurs pouvant toujours survenir, ils 
doivent aussi proposer des moyens de monitoring et de reprise. 

Ces dernieres annees, le Web et les architectures orientees services ont beneficie de nombreuses 
solutions techniques Open Source, mais aucune solution de traitement de batch Open Source ne 
s'est particulierement distinguee. Le projet Spring Batch a ete cree pour remedier a cette situation, 
afin de proposer des briques techniques pour faciliter les developpements batch en Java. 

Les societes Accenture et SpringSource sont a l'origine de ce projet, afin de faire beneficier la 
communaute Java de leur expertise a la fois technique et sur les batch dans le monde des 
applications d'entreprise. 

Spring Batch adopte le modele de programmation de Spring, en s'appuyant sur toutes ses 
briques (conteneur leger, persistance des donnees, transactions, etc.). Surtout, il propose une 
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infrastructure parfaitement adaptee aux batch. Cela comprend notamment des briques pour 
faciliter le traitement par lot de fichiers plats ou XML et des mecanismes optimises pour les 
acces aux bases de donnees. 

Grace au conteneur leger de Spring, Spring Batch laisse la possibilite au code applicatif de se 
brancher tres facilement sur son infrastructure. Le developpeur de batch peut des lors se 
concentrer sur les aspects specifiques de son application et n'a plus a se soucier de problema- 
tiques bas niveau, tels que les entrees-sorties. 

Nous detaillons dans ce chapitre les concepts propres a Spring Batch et aux batch de facon 
generate. Nous ecrirons ensuite notre premier batch afin de demystifier le framework. Les trai- 
tements batch tournant generalement autour de la lecture et de l'ecriture de donnees, nous 
veiTons le support que propose Spring Batch pour les sources de donnees les plus courantes 
(fichiers plats et XML, base de donnees). 

Nous aborderons aussi le lancement des batch en ligne de commande et finirons par des 
notions plus avancees de Spring Batch, qui mettent en jeu notamment l'historisation et la 
gestion des erreurs. 



Concepts de Spring Batch 

Nous abordons dans cette section les concepts et le vocabulaire associes aux developpements 
batch. Nous verrons ainsi comment Spring Batch s'integre dans de tels developpements et 
que lies problematiques il est capable d'adresser. 

La figure 15-1 liste les differents composants qui constituent l'ecosysteme de Spring Batch, 
afin notamment de distinguer leur origine (interne a Spring Batch, elements techniques exter- 
nes et code ou configuration applicatifs). Les differents tiers de l'ecosysteme sont aussi 
presented dans le haut de la figure (lancement, job, application et donnees). 
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Composants externes 

Les composants externes font reference a des systemes completement exterieurs au batch en 
lui-meme. 

On peut distinguer deux types de composants externes : 

• Le lancement du batch, ou plus exactement ce qui provoquera l'impulsion qui declenchera 
le batch. Un batch peut etre lance periodiquement via un programmateur (scheduler en 
anglais). Quartz est un exemple de programmateur developpe en Java, qui peut etre 
embarque dans une application Web (Spring propose un support pour Quartz). II existe 
aussi des programmateurs natifs aux systemes d' exploitation, cron en est un exemple pour 
le monde Unix, Windows dispose quant a lui des taches planifiees. Spring Batch n'est en 
aucun cas un programmateur, il laisse cette responsabilite a des projets dedies. Le lance- 
ment d'un batch peut aussi etre provoque par une impulsion externe, comme la reception 
d'une requete (requete HTTP ou message sur une pile JMS). Dans les deux cas (program- 
mateur ou requete externe), un script lancera le batch. Ce script gerera le lancement de la 
machine virtuelle Java, en positionnant correctement le classpath et en precisant les para- 
metres necessaires a Spring Batch. Nous etudions plus en detail par la suite les mecanismes 
de lancement de batch. 

• Le deuxieme type de composants externes comprend les systemes destines au stockage 
physique des donnees. Les batch communiqueront avec ces systemes pour lire et ecrire des 
donnees. Des exemples de tels composants sont les piles JMS pour recuperer des messages 
accumules, les bases de donnees et les fichiers (generalement plats ou XML). 

Notions de job et d'etape 

Un job correspond a un traitement qui est effectue lors de l'execution d'un batch (batch et job 
pourraient d'ailleurs etre utilises de maniere equivalente). Dans Spring Batch, un job est 
represente par un Bean implementant l'interface Job. Un job est compose d'un ensemble 
d'etapes (step). Les etapes d'un job sont sequentielles, c'est-a-dire qu'elles doivent etre 
executees les unes a la suite des autres. 

Un job peut, par exemple, etre constitue de trois etapes : l'une chargeant des donnees a partir 
de fichiers pour les mettre en base de donnees, une autre transformant ces donnees pour les 
inserer dans une autre table et la troisieme exportant les donnees traitees dans un fichier. 

La notion de job est cependant insuffisante pour definir completement le cycle de vie d'un 
batch. Si Ton prend l'exemple d'un batch nomme bi 1 anQuoti di en, car lance une fois par jour, 
on parlera du batch pour un jour donne arm de suivre l'historique de ces lancements. 

Spring Batch introduit la notion de Joblnstance pour faire reference a l'execution d'un batch. 
Dans l'exemple precedent, on parlerait de l'instance de job du 4 decembre 2008, de celle du 
5 decembre, et ainsi de suite. Une instance de job implique done la definition de l'identite 
d'un job, qui passe dans Spring Batch par la classe JobParameters. 

Les parametres passes a un job lors de son lancement permettent de definir completement son 
identite, c'est-a-dire l'objet Joblnstance qui le representera. Toujours dans le meme exemple, 
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Fidentite d'une instance du job pouiTait done passer par un JobParameter contenant la date du 
jour, passe aux JobParameters. 

Une instance de job peut ainsi etre resumee par F equation suivante : 

Joblnstance = Job + JobParameters 

Dans le meilleur des mondes, le batch bil anQuotidien ne serait execute qu'une fois par jour, 
car aucun probleme ne surviendrait lors de l'execution. Malheureusement, des erreurs 
peuvent survenir, et une instance de job peut etre amenee a s'executer plusieurs fois, jusqu'a 
ce que ses traitements puissent etre considered comme completes. Ainsi, l'instance du 
4decembre 2008 du batch bil anQuotidien peut n'arriver a son terme qu'au bout de la 
cinquieme execution, les quatre premieres ayant echoue. Dans Spring Batch, on parle de 
JobExecution pour marquer cette distinction. Une instance de job peut avoir une seule 
JobExecution (si tout se passe correctement la premiere fois) ou plusieurs (si quelque chose se 
passe mal). 

La figure 15-2 represente les cardinalites entre Job, Joblnstance et JobExecution. 



Figure 15-2 
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La distinction entre Job, Joblnstance et JobExecuti on permet un suivi tres precis des batch. En 
effet, Spring Batch est capable de persister en base de donnees l'historique de tous les batch 
executes, et ce de facon tres fiable. Utile en lui-meme, ce suivi permet aussi la reprise sur 
erreur des batch. 

Le contexte d'une execution de batch est en outre persiste. II est des lors possible de Futiliser 
pour reprendre une execution de batch exactement la oil elle a echoue. La tache de reprise doit 
etre prise en charge par du code applicatif dans le batch, en se fondant sur le contexte restitue 
par Spring Batch. 



Contenu d'une etape de job 

Nous avons vu qu'un job etait compose d'etapes qui s'executent sequentiellement. Dans 
Spring Batch, une etape est representee par Finterface Step. Un developpeur sera rarement 
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amene a developper ses propres classes de Step, car Spring Batch propose des implementa- 
tions prenant en charge les problematiques d' infrastructure et laissant la possibilite a du code 
applicatif d'etre execute pour les besoins propres de F application. 

Le type d'etape le plus simple propose par Spring Batch est represente par la classe 
TaskletStep, qui permet de brancher du code applicatif via Finterface Tasklet. Quand unjob 
contient une TaskletStep, celle-ci prend en charge notamment la gestion de la transaction 
« autour » de la Taskl et, qui contient, quant a elle, le code applicatif (traitements de fichiers, 
verifications ou traitements metier). 

Un autre type d'etape foumi par Spring Batch peut etre obtenu avec la classe 
SimpleStepFactoryBean, qui propose un schema d' execution lecture -transformation-ecriture. 
En effet, il est possible de parameter sur ce type d'etape un ItemReader (charge de recuperer 
des donnees depuis une source), un ItemProcessor (charge de transformer les donnees lues) et 
un ItemWriter (charge d' exporter les donnees vers un support de stockage). 

La gestion des transactions est egalement prise en charge par F implementation de Step, par 
enregistrement ou par lot d'enregistements (chunk). 

Lecture et ecriture de donnees 

La lecture et F ecriture de donnees sont des problematiques recurrentes, voire meme centrales, 
dans un batch. Nous venons de voir que Spring Batch propose une implementation de Step 
utilisant un ItemReader et ItemWriter pour respectivement lire et ecrire des donnees. 

Un framework tel que Spring Batch presente un double interet pour ces problematiques en ce 
qu'il propose a la fois un cadre d'execution fiable et robuste pour effectuer les lectures/ecritu- 
res et des implementations d'ltemReaders et d'ltemWriters pretes a etre utilisees, ou plutot 
configurees. La lecture d'un fichier plat ou XML peut done se resumer a de la configuration, 
sans avoir a ecrire une ligne de code Java. 

Spring Batch propose un support de lecture/ecriture pour de nombreux types de ressources : 
fichiers plats, fichiers XML, base de donnees (SQL ou mapping objet/relationnel). Dans 
tous les cas, Spring Batch se charge des details dits de bas niveau (ouverture/fermeture des 
flux, creation des fichiers, etc.), arm d'eviter du code penible, mais aussi de fiabiliser les 
applications. 

Nous detaillons le support de lecture/ecriture de Spring Batch plus loin dans ce chapitre. 

Gestion des batch 

Par gestion des batch, nous entendons tous les composants de Spring Batch offrant les servi- 
ces necessaires a la bonne execution d'un batch. Le JobRunner permet de lancer un batch grace 
a un JobLocator, qui lui fournit le Job. JobRunner et JobLocator sont des notions internes a 
Spring Batch, peu utiles au developpeur de batch, au moins pour les utilisations de base. 

Le JobLauncher gere F execution du batch, notamment si celui-ci doit etre lance de maniere 
synchrone (dans le meme thread que le code appelant) ou asynchrone (dans un fil d'execution 
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different). Le JobLauncher est etroitement lie ail JobReposi tory, qui gere pour sa part la persis- 
tance de l'etat du job. 

De maniere plus generale, le JobReposi tory gere le cycle de vie de tout lancement de job, 
c'est-a-dire les instances de jobs, mais aussi leurs executions associees, ainsi que leur 
contexte. Cette fonctionnalite est tres utile pour le monitoring des batch comme pour la 
reprise sur erreur. Le JobReposi tory persiste ses donnees dans une base de donnees, mais il est 
possible de ne rien persister en utilisant une implementation de JobRepository travaillant en 
memoire. 

En resume 

Spring Batch propose un veritable cadre de travail pour les applications utilisant des batch. 
Fidele aux principes de Spring, Spring Batch propose une infrastructure gerant la plupart des 
problematiques techniques (transaction, repetition, reprise) arm de laisser le developpeur se 
concentrer sur le code applicatif . 

Les executions de batch peuvent etre tracees grace au systeme de persistance, qui facilite aussi 
la reprise sur erreur d'une instance de batch. Spring Batch propose aussi un support pour la 
lecture et Fecriture de donnees pour les principaux types de ressources (fichiers, base de 
donnees). 

Premiers pas avec Spring Batch 

Spring Batch fournissant de nombreux elements pour creer et executer des batch, une grande 
part de son utilisation consiste en de la configuration. 

Nous allons voir comment configurer et executer un batch tres simple se contentant d'afficher 
un message dans la console. Nous aborderons cependant tous les elements essentiels de confi- 
guration, au moins pour les besoins les plus frequents. La version de Spring Batch utilisee 
dans ce chapite est la 2.0.0. 

Note batch est compose d'une seule etape et utilise le type d'etape le plus simple, la 
TaskletStep. Le point d' extension sur lequel vient se brancher le code applicatif dans une 
TaskletStep est la Tasklet. 

Voici note implementation de Tasklet : 
package tudu. batch. tasklet; 

import org.springf ramework. batch. core. ExitStatus; 

import org.springf ramework. batch. core. StepContributi on; 

import org. springf ramework. batch. core. scope. con text. Chun kCon text; 

import org. springf ramework. batch. core. step. tasklet. Tasklet; 

import org. springf ramework. batch . repeat . RepeatSt at us ; 

public class HelloTasklet implements Tasklet { 



public RepeatStatus execute(StepContribution stepContribution, 
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ChunkContext chunkContext) throws Exception { 
System. out .pri ntln( "Hello world! " ) ;<— © 
stepContributi on. set ExitStatus( ExitSt at us .COMPLETED) ; <— © 
return RepeatStatus.FINISHED;<— © 



Taskl et definit une seule methode, execute, qui doit retoumer un RepeatStatus. Ce statut indi- 
que a Spring Batch si la tache doit etre repetee ou pas. Les parametres de execute correspon- 
dent a une partie du contexte de Fetape (d'ou son nom, StepContributi on) et a un conteneur, 
ChunkContext, qui represente le contexte d' execution pour un ensemble d'elements traites. 

Dans notre exemple, nous nous contentons d'afficher un message dans la console (©). Nous 
indiquons au repere © que Fetape est terminee et au repere © que la tache n'a pas a etre 
repetee au sein de cette etape. Le statut de sortie et le statut de repetition peuvent sembler 
redondants, mais il s'agit bien de deux choses distinctes. Le statut de sortie pourrait indiquer 
aussi que la tache a echoue ou qu'elle a du etre interrompue, ce qui est compatible avec un 
statut de repetition « termine ». Nous entrerons dans les details des notions de repetition et de 
reprise par la suite. 

Nous en avons fini avec Fecriture du code Java de notre batch, le reste consistant en de la 
configuration au travers d'un fichier XML. 

Depuis sa version 2, Spring Batch propose un schema XML destine a la configuration des 
differents elements composant un batch. 

Voici la declaration de ce schema : 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns :batch="http: //www. springframework.org/schema/batch" 

xmlns:p=" http://www.springframework.Org/schema/p" 
xsi : schema Location-" http://www.spr ingframework.org/schema/beans 
http: //www. springf ramework. org/schema /beans /spring- beans .xsd 
http: //www.springf ramework. org/schema /batch 

http: //www.springf ramework. org/schema /batch/ spring -batch -2.0. xsd" > 



La configuration consiste dans un premier temps en la declaration de F infrastructure neces- 
saire a tout job de Spring Batch : 

<bean id="transactionManager" 

cl ass-" org. springf ramework. batch. support. transact ion.** 
Resourcel essTransactionManager" /><— © 

<bean id="jobRepository" 

class-" org. springf ramework. batch. core. repository .support.** 
MapJobReposi to ry Factory Bean" <— © 
p: transact!' onManager-ref=" transact!' onManager" /><— Q 



</bean> 



Technologies d'integration 

Partie IV 



<bean id=" jobLauncher" 

cl ass="org.springf ramework. batch. core. launch. support.* 
Simpl eJobLauncher"<— Q 
p: jobRepository-ref="jobRepository" /><— Q 

Notre configuration correspond a une infrastructure utilisee pour le developpement ou les 
tests. Nous definissons un gestionnaire de transactions vide, Resource"! essTransactionManager 
(©)■ Spring Batch etant fortement transactionnel, le gestionnaire de transactions est une 
dependance essentielle. 

Nous passons ensuite a la declaration du depot de job (Q), ou nous optons pour une imple- 
mentation adaptee aux tests, car effectuant le stockage des informations en memoire. Cette 
implementation necessite le gestionnaire de transactions, que nous lui injectons avec l'espace 
de nommage p pour plus de concision (©). Nous passons ensuite au lanceur de job, pour 
lequel nous utilisons F implementation par defaut fournie par Spring Batch (Q). Le lanceur de 
job necessite une reference au depot de job (0), car c'est ce dernier qui cree l'instance de job. 

Nous venons de configurer les elements essentiels de Spring Batch, que nous retrouvons dans 
tout batch. Nous avons opte pour une configuration commode, utilisant les implementations 
adaptees aux tests, mais les veritables implementations ne sont guere plus complexes a confi- 
gurer. 

Nous pouvons passer maintenant a la configuration du job : 

<batch:job i d="hel 1 oJob" job-repository="jobRepository"><— Q 
<batch:step i d=" hel 1 oStep" >< — Q 

<batch: taskl et ref="hel 1 oTaskl et"<— Q 
t r ans act ion -manage r=" trans act i onManager"/> 
</batch:step> 
</batch: job> 

<bean id="helloTasklet" 

cl a ss="tudu. batch. t as klet. Hel 1 oTaskl et" /><— © 

A travers F element job, nous utilisons une implementation par defaut de job (Q) qui neces- 
site le depot de job pour tracer le deroulement de F execution et une liste d'etapes. Notre job 
n'est compose que d'une etape, definie avec la balise step et dont l'identifiant est helloStep 
Q). La Taskl et definie precedemment est declaree au repere 0. Elle est referencee aupres de 
Fetape avec Fattribut ref de la balise taskl et (©). 

Si le depot de job et le gestionnaire de transactions sont des dependances obligatoires pour 
certains elements, il est possible de les omettre. En ce cas, Spring Batch effectuera une reso- 
lution par defaut. Cette resolution s'appuie sur les noms des Beans, qui doivent etre 
jobRepository et transact!' onManager. Ce comportement permet d'alleger la configuration 
tant que la convention de nommage est respectee. Ce raccourci est utilise dans les exemples de 
ce chapitre afin d'ameliorer leur lisibilite. 

La definition de notre job etant terminee, nous pouvons Fexecuter, par exemple, via un 
programme main afin d'afficher notre message : 
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import org. springf ramework. batch .core .Job; 
import org. springf ramework. batch . core . JobExecut ion ; 
import org. springf ramework. batch . core . JobParameters ; 
import org. springf ramework. batch . core . 1 aunch . Job Launcher ; 
import org. springf ramework. context . Appl i cationContext ; 
import org. springf ramework. context. support. 

CI assPathXml Appl icationContext; 

(...) 

public static void main(String [] args) { 
Appl icationContext context = new CI assPathXml Appl icationContext( 
"hellojob-context.xml " 

); 

Job job = (Job) context .getBeant "hel 1 oJob" ) ; 
JobLauncher jobLauncher = (JobLauncher)context. 

getBeanC'jobLauncher") ; 

JobExecution exec = jobLauncher. run(job, new JobParameters( ) ) ;<— Q 

} 

Nous utilisons au repere© une nouvelle instance de JobParameters pour lancer notre job. 
C'est a partir de cette instance que Fidentite de notre instance de job est constitute et que le 
depot de job peut suivre revolution des executions, d'un lancement a l'autre (dans le cas ou 
les executions sont veritablement persistees). Les parametres de job ne sont generalement pas 
passes de facon programmatique, mais plutot par les programmateurs, via des parametres 
dans la ligne de commande. Ces parametres correspondent souvent a des informations tempo- 
relies, comme pour notre job de bilan quotidien du 4 decembre 2008. 

La configuration de ce job tres simple nous a permis d'aborder la plupart des points essentiels 
a tout lancement de job. Nous allons maintenant pouvoir aborder chacun de ces points de 
facon plus detaillee et surtout voir la richesse des fonctionnalites apportees par Spring Batch. 



Lecture, transformation et ecriture de donnees 

Un cas d'utilisation courant dans un batch consiste en Fimportation (lecture) de donnees 
depuis une source (fichiers, base de donnees), la transformation de ces donnees puis en leur 
exportation (ecriture) sous cette nouvelle forme vers une autre source. 

Pour repondre a ce besoin recurrent, Spring Batch propose un type d'etape specifique, qui 
fonctionne selon le schema lecture-transformation-ecriture. II est important de noter que 
l'etape de transformation est optionnelle, ce qui peut correspondre a une lecture de donnees 
depuis un fichier plat et a leur restitution a Fidentique dans une base de donnees. Son interet 
peut resider dans la possibilite d'utiliser la base de donnees pour effectuer des requetes 
complexes, comme des fonctions d'agregation (groupement, somme, etc.). 

Nous allons voir dans cette partie quelles sont les classes et interfaces impliquees dans le 
mecanisme de lecture-transformation-ecriture, puis nous aborderons differentes implementations 
proposees par Spring Batch. 
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Principes et composants impliques 

L'interface correspondant a la lecture de donnees est ItemReader, dont voici la definition : 
package org. spri ngframework. batch. item; 

public interface ItemReader<T> { 

T readO throws Exception, UnexpectedlnputException, 
ParseException; 

} 

La methode read d'un ItemReader est appelee successivement au sein d'une etape et retourne 
des objets du type pour lequel il est defini (parametre T de l'interface). Une fois la ressource 
de lecture epuisee, la methode read doit retourner null, mettant ainsi fin a la lecture. Spring 
Batch fournit un ensemble d' implementation d' ItemReader, destinees aux sources de donnees 
les plus courantes. 

L'interface correspondant a la transformation est ItemProcessor, dont voici la definition : 
package org. spri ngframework. batch. item; 

public interface ItemProcessoKI , 0> { 

0 processd item) throws Exception; 

) 

L'interface dispose de deux parametres de types, qui correspondent respectivement au para- 
metre d'entree de sa methode process (parametre d' entree issu de la lecture) et a l'objet 
retourne par process (objet destine ensuite a l'ecriture). Contrairement a ItemReader, les 
implementations d' ItemProcessor sont plutot ecrites par le developpeur de batch, car elles 
correspondent a des besoins fonctionnels. 

Enfin, l'interface correspondant a l'ecriture est ItemWriter : 
package org. spri ngframework. batch. item; 

import java.util .List; 

public interface Itemwriter<T> { 

void write(List<? extends T> items) throws Exception; 

} 

Un Itemwriter ecrit les objets qui lui arrivent d'un ItemProcessor ou alors directement depuis 
un ItemReader s'il n'y a pas de transformation dans l'etape. Contrairement aux deux autres 
interfaces, un Itemwriter travaille avec une liste d'objets, permettant ainsi un travail par lot. 
Ce besoin est dicte par de potentielles problematiques de performances, car il est generalement 
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plus rapide d'effectuer des ecritures par lot qu'unitaires, notamment au sein de transactions 
avec une base de donnees. 

L' orchestration des trois elements que nous venons de presenter est effectuee via la balise taskl et. 

Voici la configuration typique d'une etape de job correspondant au schema lecture-transfor- 
mation-ecriture : 

<batch:job id="job"> 
<batch:step id="step"><— Q 
<batch:tasklet> 
<batch: chunk 

reader="i temReader"<— Q 
processor="i temProcessor"<— Q 
writer="itemWriter"<— Q 
commit-interval="10" /><— Q 
</batch:chunk> 
</batch :taskl et> 
</batch : step> 
</batch: job> 

Letape est creee avec la balise step (0). La balise chunk imbriquee dispose d'attributs corres- 
pondant aux phases de lecture, transformation et ecriture (Q, Q, Q). Le Bean correspondant 
a la transformation est optionnel, s'il n'est pas present, les objets a lire et a ecrire sont done les 
merries. L'attribut commit -interval (©) permet de regler le nombre d'elements lus avant que 
leur ecriture soit validee via le gestionnaire de transactions (il s'agit de la faille d'un lot). Nous 
revenons sur ce parametre plus loin dans ce chapitre. 

La declaration d'une etape fondee sur le schema lecture-transformation-ecriture est done 
generique. Nous allons voir ce que propose Spring Batch pour differents supports de donnees, 
a travers des implementations d'ltemReader et d'ltemWriter. 



Support pour les fichiers plats 

Les fichiers plats, de par leur simplicite, sont un support privilegie pour l'echange de donnees. 
II y a deux grandes categories de fichiers, ceux utilisant un delimiteur entre chaque champ et 
ceux utilisant des longueurs de champ fixes. Les fichiers plats avec delimiteur etant les plus 
courants, nous allons privilegier leur etude, sachant que le support de Spring Batch pour les 
deux types est tres proche et suit les memes principes. 

Prenons l'exemple de l'import et de l'export de TodoLists. Voici le format du fichier plat 
correspondant (les proprietes sont dans l'ordre Fidentifiant, le nom, le fait qu'un flux RSS est 
autorise et la date de mise a jour) : 

1, Spring par la pratique, true, 2008-11-29 
2,Tudu Lists (a Spring appl i cation) ,fal se, 2008-11-25 
3, Spring 3.0, true, 2008-11-20 

L'import de ce type de fichier consiste en la configuration d'un ItemReader fourni par Spring 
Batch. Nous allons voir que l'utilisation d'un tel ItemReader implique principalement de la 
configuration et le developpement d'une seule classe applicative dediee. 



Technologies d'integration 

Partie IV 



La figure 15-3 illustre les differentes classes et interfaces mises en jeu pour la lecture du 
fichier plat de TodoLists. 
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Le premier constat est qu'un grand nombre de classes sont impliquees : c'est le prix a payer 
pour Fextensibilite et la reutilisabilite. Voici le code XML correspondant a la configuration de 
notre fichier plat : 

<bean id-"todol_istFi 1 eltemReader" 
class="org.springframework.batch.item.file.FlatFileItemReader"><— Q 
<property name=" resource" value="file: ./todolists.csv" /><— Q 
<property name="l ineMapper"> 

<bean cl ass-" org.springf ramework.ba tch.item.fi le. mapping. 
Def a ul t LineMapper "><—© 
<property name="l ineTokenizer"> 
<bean 

cl ass-"org.springf ramework.ba tch. item.fi le. transform. 

Del imitedLineTokenizer"><— Q 
<property name="names" 

val ue-"id .name , rssAl 1 owed , 1 astUpdate" /><— Q 

</bean> 
</property> 

<property name="f iel dSetMapper"> 
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<bean class="tudu. batch. item. TodoListFieldSetMapper" /><— Q 
</property> 
</bean> 
</property> 
</bean> 

La configuration commence par la declaration du Fl atFi 1 eltemReader (Q), qui se charge des 
entrees/sorties (ouverture et fermeture du fichier, iteration sur les lignes, etc.). Ce genre 
d'operation peut etre en effet particulierement penible en Java et propice a des erreurs. 

Le fichier a lire est precise via une Resource (0), notion venant de Spring (et non pas de 
Spring Batch). Le travail du Fl atFi 1 eltemReader est de fournir, pour chaque ligne du fichier 
d'entree, une representation objet correspondante. II va pour cela deleguer le travail a un 
LineMapper. Nous utilisons ici la classe DefaultLineMapper (0), qui delegue aussi une paitie 
de son travail. Elle utilise DelimitedLineTokenizer (0) pour decomposer chaque ligne sous 
forme d'un FieldSet. Un FieldSet est l'equivalent pour un fichier d'un ResultSet pour une 
base de donnees. Le FieldSet stocke les donnees de la ligne sous un ensemble de paires cle/ 
valeur. Les cles sont indiquees au repere 0. 

Le DelimitedLineTokenizer doit connaitre le separateur des champs pour alimenter correcte- 
ment le FieldSet. II utilise par defaut la virgule comme separateur, ce qui convient parfaite- 
ment a notre fichier d'entree. Enfin, une fois le FieldSet genere (pour chaque ligne) par le 
DelimitedLineTokenizer, il est passe a un FieldSetMapper, charge de creer Fobjet applicatif 
attendu. II s'agit la de la seule classe applicative, qui doit etre ecrite par le developpeur de batch. 

Voici notre implementation de FieldSetMapper, permettant de passer du FieldSet a une 
TodoList : 

package tudu. batch. item; 

import org.springframework.batch.item.file. mapping. FieldSetMapper; 
import org. springframework.batch.item.file. transform. FieldSet; 

import tudu. domain. model .TodoList; 

public class TodoListFieldSetMapper 

implements FieldSetMapper<TodoList> { 

public TodoList mapFieldSet(FieldSet fs) { 
TodoList todoList = new TodoListO; 
todoList . set Li stld(fs . readString( "id" ) ) ; 
todoLi st . setName(fs . readStri ng( "name" ) ) ; 
todoLi st . setRssAl 1 owed(f s . readBool ean( "rssAl 1 owed" ) ) ; 
todoLi st . setLastUpdate(f s . readDate( "1 as t Update" ) ) ; 
return todoList; 

} 



} 
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Le FieldSetMapper de Spring Batch se rapproche beaucoup du RowMapper de Spring, car il a 
flnalement le meme role, si ce n'est que le FieldSet vient d'un fichier et non d'une base de 
donnees. Nous voyons tout l'interet du FieldSet, qui affranchit le developpeur des conver- 
sions de chaines de caracteres vers d'autres types, grace a ses methodes readBoolean, 
readDate, etc. La TodoList retournee par le FieldSetMapper correspond a l'objet retourne par 
F ItemReader. Nous avons ici un exemple d'inversion de controle au sens framework du terme, 
car le code applicatif est bien appele par le code de Spring Batch. 

Nous allons voir maintenant l'operation inverse, qui consiste a ecrire des TodoLists dans un 
fichier plat. Ces TodoLi sts peuvent etre le resultat d'une requete en base de donnees, mais cela 
importe flnalement peu, car nous nous concentrons sur leur exportation. 

Voici un exemple de configuration XML correspondant a l'exportation de TodoLists : 

<bean id-"todoListItemWriter" 
class="org.springframework.batch.item.file.FlatFileItemWriter"><— Q 
<property name=" resource" value-"file: . /todol i sts . csv" /><— Q 
<property name="l ineAggregator"><— Q 

<bean class="tudu. batch. item. TodoListLineAggregator" /><— Q 
</property> 
</bean> 

Le type d' ItemWriter utilise est un FlatFileltemWriter (Q). On doit lui indiquer le chemin 
du fichier d'export (Q) sous la forme d'une Resource, ce qui permet d'utiliser la syntaxe 
correspondante. II necessite aussi un Li neAggregator (©), qui permet, a partir d'un objet Java, 
d'obtenir sa representation sous forme d'une chaine de caracteres, correspondant a une ligne 
dans le fichier d'export. Les implementations de Li neAggregator correspondent la plupart du 
temps a du code applicatif (Q). 

Voici 1' implementation de TodoListsLineAggregator, permettant, a partir d'une TodoList, 
d'obtenir une ligne au format correct pour notre fichier d'export : 

package tudu. batch. item; 

import java .text .Simpl eDate Format; 

import org. springframework. batch. item. file. transform.* 

LineAggregator; 
import tudu. domain. model .TodoList; 

public class TodoListLineAggregator 
implements LineAggregator<TodoList> { 

private String separator = ","; 

public String aggregate(TodoLi st item) { 
StringBuilder builder = new Stri ngBui 1 der( ) ; 
bui 1 der. append ( item. get List Id ( ) ) ; 
builder. append (separator) ; 
bui 1 der. append ( item. get Name ( ) ) ; 
builder. append (separator) ; 
bui 1 der . append ( item. i sRssAl 1 owed( ) ) ; 
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builder. append (separator) ; 

Simpl eDateFormat dateFormat = new Simpl eDateFormat( 
"yyyy-MM-dd"); 

bui 1 der .append (dateFormat . format ( item. get LastUpdate( ) ) ) ; 
return bui lder . toStri ng( ) ; 

} 

} 

Cette implementation de LineAggregator plutot simple ne correspond qu'a l'ecriture des 
proprietes de la TodoList separees par des virgules. La encore, le code applicatif se retrouve 
completement integre au flot d'execution, mene par Spring Batch, qui se charge des taches les 
plus repetitives (ouverture/fermeture du flux vers le fichier de sortie, ajout du separateur de fin 
de ligne, etc.). 

Nous venons de voir les bases du support de Spring Batch pour la gestion des fichiers plats. II 
s'agit bien la des bases, car les composants fournis disposent d'un grand nombre d' options, 
qu'il serait trop long d'aborder ici. Nous enjoignons le lecteur a consulter la documentation de 
reference de Spring Batch pour avoir le detail de ces options. 

Voici neanmoins quelques points importants facilement parametrables : 

• Gestion des delimiteurs de separation 

• Pour la lecture, gestion de Fencodage, de lignes correspondant a des cornmentaires, de 
lignes d'en-tete, etc. 

• Possibilite de lire des fichiers ou un meme enregistrement se divise sur plusieurs lignes. 

• Pour l'ecriture, gestion de Fencodage, de Fen-tete et du pied du fichier via des methodes de 
rappels. 



Support pour les fichiers XML 

Spring Batch propose un support pour la lecture et l'ecriture de fichiers XMLfonde sur 1' API 
d' analyse StAX et le principe de mapping objet/XML. 

L'usage de StAX se justifie par la non-adequation des autres standards d' analyse XML (DOM 
et SAX) avec les besoins des traitements batch. DOM charge en effet les fichiers XML en 
memoire, ce qui n'est pas envisageable pour les fichiers de grande faille. Quant a SAX, son 
modele evenementiel ne propose que des methodes de rappel lors de 1' analyse du fichier. 
Globalement, l'avantage de StAX reside dans la possibilite de diriger un curseur au sein du 
document : 1' analyse reste ainsi commode, tout en ne consommant que peu de memoire. 

Spring Batch considere qu'un fichier XML est compose de fragments, chacun representant un 
enregistrement. Un fragment XML est F equivalent de la ligne d'un fichier plat. 

Voici un exemple de fichier XML contenant trois fragments, un pour chaque TodoLi st : 
<todol i sts> 

<todolist id="l" name="Spring par la pratique" 

rssAllowed="true" 1 astUpdate="2008-ll-29" /> 
<todolist id="2" name="Tudu Lists (a Spring application)" 

rssAllowed="false" 1 astUpdate="2008-ll-25" /> 
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<todolist id="3" name="Spri ng 3.0" 

rssAllowed="tme" lastUpdate="2008-ll-20" /> 
</todol i sts> 

Dans cet exemple, la balise todol i sts est la racine et doit etre indiquee en tant que telle a 
Spring Batch pour l'analyse, de meme que Ton doit lui indiquer que la balise todol i st corres- 
pond a un fragment. Spring Batch effectue ensuite un mapping objet/XML. Pour ce mapping, 
Spring Batch n'est lie a aucune technologie, mais propose un support natif pour Spring OXM, 
qui constitue une abstraction vers les solutions de mapping objet/XML les plus populaires 
(JaxB2, Castor, etc.). Pour nos exemples, nous utiliserons Spring OXM et son support pour 
XStream. 

Voici la configuration d'un ItemReader permettant de creer des TodoLists a partir du fichier 
XML vu precedemment : 

<bean id— "todoLi stFi 1 e ItemReader" 
class="org.springframework.batch.item.xml .StaxEvent ItemReader "><— Q 
<property name="resource" value-"file: ./todolists.xml " /><— Q 
<property name="f ragmentRootEl ementName" value="todolist" /><— Q 
<property name="unmarshal 1 er" ref="tudul_istMarshal ler" /><— Q 

</bean> 

<bean id— "tuduLi stMarshal 1 er" 
cl ass-"org.spri ngf ramework.oxm.xstream.XStreamMarshal 1 er"><— Q 
<property name="al iases" ref-"al i ases" /> 
</bean> 

<util:map id="al iases"><— Q 

<entry key="todol ist" value="tudu. domain. model .TodoList" /> 

<entry key=" 1 i st Id" value="java.lang. String" /> 

<entry key="name" value="java.lang. String" /> 

<entry key="rssAl lowed" val ue="bool ean" /> 

<entry key="l astUpdate" val ue="java . uti 1 . Date" /> 
</uti 1 :map> 

Spring Batch propose une implementation d' ItemReader effectuant l'analyse d'un fichier 
XML via StAX, StaxEventltemReader (Qi). Le parametrage du fichier d'entree se fait avec un 
objet de type Resource (Q), ce qui permet d'utiliser la syntaxe correspondante. Nous devons 
preciser a Spring Batch quelle balise correspond a un fragment (©), ce qui permet de lancer 
pour chaque occurrence la phase de mapping via un Unmarshaller (Q), interface venant de 
Spring OXM (le terme « marshalling » correspond a la serialisation d'un objet Java sous une 
forme XML). 

Nous utilisons une implementation utilisant XStream (©), qui necessite une simple Map pour 
preciser le mapping (©). XStream est particulierement adapte aux cas simples, car il neces- 
site peu de configuration. Pour des besoins plus avances, une bibliotheque telle que Castor 
peut s'averer necessaire. 

Contrairement aux fichiers plats, aucune classe applicative n'est ici necessaire. La lecture des 
TodoLi sts depuis un fichier XML est realisee completement a partir d'elements de configuration. 
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Spring Batch prend encore en charge les problematiques techniques de lecture et d' analyse du 
fichier XML, laissant la possibilite de se brancher sur n'importe quel type d'outil de mapping 
objet/XML grace a Spring OXM. 

L' export de TodoLists vers un fichier XML demande une configuration un peu plus complexe, 
dependant principalement de l'outil d'OXM (toujours XStream dans Fexemple suivant) : 

<bean id-"todol_istItemWriter" 
cl a ss=" org. springf ramework. batch. item. xml . StaxEventltemWri ter"><— Q 

<property name="resource" val ue-"f i le: ./todol ists .xml " /><— Q 

<property name="rootTagName" value="todolists" /><— Q 

<property name="marshal 1 er" ref="tuduLi stMarshal 1 er" /> 
</bean> 

<bean id-"tuduListMarshaller" 
cl ass-"org. springf ramework. oxm. xstream. XStreamMars ha 1 1 er"><— Q 
<property name="al i ases" ref="aliases" /><— Q 
<property name="useAttributeForTypes"><— Q 
<list> 

<val ue>java. lang.String</val ue> 
<val ue>bool ean</val ue> 
<value>java.util . Date</val ue> 
</list> 
</property> 

<property name="omittedFi el ds"><— Q 
<map> 

<entry key-"tudu. domain. model .TodoList" value="users,todos"/> 
</map> 
</property> 

<property name="converters" ref="dateConverter" /><— Q 
</bean> 

<bean id="dateConverter" 

cl as s=" com. thoughtworks .xstream. converters .basi c. DateConverter"><— © 

<constructor-arg val ue="yyyy-MM-dd" /> 

<constructor-arg val ue="yyyy-MM-dd" /> 
</bean> 

<util:map id="al iases"><— © 

<entry key="todol i st" val ue="tudu. domain. model .TodoList" /> 

<entry key="listld" value="java.lang. String" /> 

<entry key="name" value="java.lang. String" /> 

<entry key-"rssAllowed" val ue="bool ean" /> 

<entry key="l astUpdate" value="java.util .Date" /> 
</util :map> 

Nous utilisons pour Tecriture du fichier XML un StaxEventltemwriter (Q) et indiquons le 
fichier destination avec la propriete resource (Q), ainsi que la balise racine a utiliser (©). 

Pour chaque TodoList, Spring Batch va utiliser un Marshal ler charge de la serialisation objet- 
XML. Sa definition (Q) passe une Map (©, ©) definissant des correspondances entte des 
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classes et des noms de balises (ou d'attributs XML). Nous precisons (0) que nous desirons 
utiliser des attributs pour certains types de donnees. Comme nous ne voulons serialiser que les 
informations de base d'une TodoList, nous precisons les noms de proprietes que nous 
excluons de la serialisation (0). Enfin, pour suivre parfaitement la syntaxe du fichier XML, 
nous precisons le format de date (0, 0). La encore, nous n'effectuons que de la configuration, et 
aucune classe applicative n'est necessaire. 

Le support XML offert par Spring Batch se charge done des mecaniques de lecture et d'ecri- 
ture, et ce de maniere optimale grace a l'API St AX. Les principales difficultes tiennent au 
choix d'un outil de mapping objet/XML et a sa configuration. Grace a sa parfaite integration 
avec Spring OXM (issue du projet Spring Web Services), Spring Batch peut s'interfacer avec 
les outils de mapping XML les plus courants. 



Support pour les bases de donnees 

Les bases de donnees relationnelles restent le principal moyen de stockage de toute applica- 
tion d'entreprise. Pour une application Web, les donnees manipulees restent limitees, car 
filtrees selon des criteres, principalement parce qu'elles sont destinees a un utilisateur humain 
qui ne peut exploiter d'enormes volumes. En revanche, dans des batch, les volumes peuvent 
etre tres importants, car ils correspondent souvent au contenu complet de tables. 

Illustrons la problematique d' optimisation pour une lecture de donnees. Aussi bien dans une 
application Web que dans un batch, nous voulons une representation objet des donnees. Spring 
propose pour cela la notion de RowMapper, qui permet de creer un objet Java a partir d'un 
ResultSet JDBC : 

public class TodoListSqlMapper 

implements Parameter!' zedRowMappeKTodoLi st> { 

public TodoList mapRow( Resul tSet rs, int rowNum) 
throws SQLException { 
TodoList tl = new TodoListO; 
tl .set Li stld(rs .getString( "id" ) ) ; 
tl . set Name ( rs . getString( "name" ) ) ; 
tl . setRssAl 1 owed ( rs .get Bool ean( "rssAl 1 owed" ) ) ; 
tl . setLastUpdate( rs .get Date ( "1 astUpdate" ) ) ; 
return tl ; 

} 

} 

Si une requete effectuee avec un JdbcTemplate retourne un million d'enregistrements, la 
methode mapRow du RowMapper sera executee un million de fois, et, surtout, le million d'instan- 
ces creees sera stocke en memoire. Cette solution n'est evidemment pas envisageable. Spring 
Batch propose des moyens d'optimiser les acces a une base de donnees lorsque de grands 
volumes sont retournes. 
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Ces optimisations se traduisent par deux approches distinctes, pour lesquelles Spring Batch 
propose un support natif : 

• L' approche par curseur, qui correspond a la recuperation des enregistrements en « streaming », 
c'est-a-dire que les resultats ne sont pas recuperes en une seule fois, mais en continu. 

• L' approche par pagination, qui consiste a paginer les resultats, c'est-a-dire a effectuer 
plusieurs requetes pour recuperer les resultats en lots. 

Nous allons voir la configuration de ces deux approches dans Spring Batch, chacune corres- 
pondant a une classe d'ltemReader et a un ensemble d'options. 

Voici la configuration de Fapproche par curseur, recuperant l'ensemble des TodoLists dans 
une base de donnees : 

<bean id="todol_istCursorItemReader" 

cl a ss=" org. springframework. batch. item. database. 
JdbcCursorItemReader"><— Q 
<property name="dataSource" ref="dataSource" /><— Q 
<property name="rowMapper"> 

<bean class-"tudu. batch. item. TodoListSqlMapper" /><— Q 
</property> 

<property name="sql "Xval ue> 

select id,name,rssAllowed,lastUpdate from todo_list<— Q 
</val ue></property> 
</bean> 

Nous utilisons un JdbcCursorltemReader (Q), qui necessite une reference a une DataSource 
Q). Nous lui assignons aussi un RowMapper (©), dont la definition a ete presentee precedem- 
ment. Ce sont les objets crees par ce RowMapper qui seront retournes par la methode read de 
1'ItemReader. Enfin, nous precisons la requete SQL a effectuer (Q). 

L'interet du JdbcCursorltemReader reside dans sa gestion « paresseuse » des enregistrements, 
qui ne sont pas recuperes en une seule fois, comme on pourrait le faire avec un JdbcTempl ate. 
II prend aussi en charge des problematiques assez techniques, car si F ItemWri ter qui recoit les 
enregistrements par paquet est lui aussi transactionnel, le ResultSet maintenu pour la lecture 
doit fonctionner sur plusieurs transactions, qui sont validees au fur et a mesure. La simplicite 
apparente de la configuration du JdbcCursorltemReader cache des mecanismes relativement 
complexes, et nous enjoignons le lecteur a consulter la documentation de reference pour avoir 
le detail de toutes les options. 

La seconde approche fournie par Spring Batch pour optimiser les acces base de donnees 
retournant beaucoup de donnees est la pagination. Voici la configuration correspondant a la 
recuperation de toutes les TodoLists : 

<bean i d="todol_ist Paging I temReader" 

cl a ss=" org. springframework. batch. item. database. 
JdbcPagi ngItemReader"><— Q 
<property name="dataSource" ref="dataSource"/><— Q 
<property name="queryProvider"> 

<bean class-" org. springframework. batch. item. database. support. 
Hsql PagingQueryProvider"><— Q 
<property name="sel ectCl ause" 
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val ue="sel ect id,name,rssAllowed,lastllpdate" /><— Q 
<property name="f romCl ause" value="from todcM ist "/><—© 
<property name="sortKey" val ue="id"/><— Q 
</bean> 
</property> 

<property name="pageSize" val ue="50"/><— Q 
<property name="rowMapper"><— Q 

<bean class="tudu. batch. item. TodoListSqlMapper" /> 
</property> 
</bean> 

Nous utilisons un JdbcPagingltemReader (0), qui necessite pour fonctionner une DataSource 
Q). II delegue la generation des instructions SQL a un Pagi ngQueryProvi der (©), dont Spring 
Batch fournit des implementations adaptees aux differentes bases de donnees du marche 
(nous utilisons ici une implementation pour HSQLDB). Nous definissons aux reperes Q et 0 
Fossature de la requete et precisons surtout une instruction pour le tri (©). La taille de 
chacune des pages est precisee a F ItemReader avec la propriete pageSi ze (Q). Nous precisons 
enfin le RowMapper a utiliser (©). 

Le JdbcPagingltemReader permet ainsi de diviser les enregistrements manipules en blocs de 
petites tailles, ce qui garantit une utilisation memoire plus optimisee. Son interaction avec 
FltemWriter travaillant de concert avec lui est exactement la meme que pour les autres 
ItemReaders. 



Batch et mapping objet/relationnel 

Les outils de mapping objet/relationnel n'ont generalement pas bonne reputation pour les programmes 
batch. En effet, un outil tel qu'Hibernate dispose de deux caracteristiques de fonctionnement qui le rendent 
particulierement inadapte a des traitements batch. Pour une meme session de travail, il garde en memoire 
tous les objets qu'on lui a demande de charger, ce qui peut provoquer rapidement une saturation de la 
memoire. A cela se rajoute le fait qu'Hibernate effectue des verifications sur les objets qu'il garde en 
session afin de savoir s'ils ont ete modifies et done de synchroniser leur etat avec la base de donnees (on 
parle de dirty checking). Sur un grand nombre d'objets, ces verifications peuvent se reveler catastrophi- 
ques pour les performances. C'est exactement le cas de figure rencontre dans un batch : de nombreux 
objets sont charges ; Hibernate verifie leur modification ; et I'on observe une baisse progressive des 
performances du traitement. Hibernate est a la base un outil pour les applications Web, role qu'il remplit 
parfaitement, notamment grace aux deux caracteristiques que nous venons de decrire. II est cependant 
possible d'utiliser Hibernate dans le monde des batch, car il propose un fonctionnement degrade sous la 
forme de la StatelessSession, qui ne garde pas les objets charges en memoire. On peut alors utiliser 
Hibernate sans crainte dans des traitements batch et profiter de la puissance de ses aspects structurels 
(mapping objet/relationnel, systeme de requetage). Spring Batch propose un support pour de la lecture 
par curseur via Hibernate, ainsi que de la pagination avec JPA. 



Nous venons de voir le support que Spring Batch propose pour la lecture a base de requetes 
SQL. Concernant Fecriture, Spring Batch ne fournit aucun mecanisme, car les insertions 
d'enregistrements en base de donnees ne peuvent etre generalisees facilement. La methode 
conseillee consiste done a utiliser ses propres DAO, en leur faisant implementer Finterface 
ItemWriter. 
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Lancement des batch 

Le framework ne propose pas de support avance de lancement des batch. Nous allons cependant 
voir quelques elements cles pour lancer des batch. 

Les batch sont la plupart du temps lances automatiquement, a heure fixe. Ce travail est effec- 
tue par un programmateur, comme cron ou Quartz. Le lancement a proprement parler se fait le 
plus souvent grace a un script shell. Les batch peuvent etre aussi lances via des impulsions, 
comme une requete HTTP. Nous verrons ce qu'implique un tel lancement. 

Spring Batch propose une classe Java contenant une fonction main, destinee a lancer un batch 
en invoquant la machine virtuelle Java. 

Voici un exemple d'utilisation de cette classe (sous Windows) : 

java -cp "./lib/main/*"<— Q 

org. springframework. batch. core. launch. support. 

Command Li neJobRunner<— Q 
cl asspath: /tudu/batch/taskl et/Hel 1 oTaskl etTest - context .xml <— Q 
helloJob<— O 

La commande commence par 1' invocation de la machine virtuelle Java et le reglage du chemin 
des classes (©). La classe de lancement fournie par Spring batch est indiquee au repere Q. 
Les deux parametres suivants de la ligne de commande correspondent aux parametres passes 
a la classe CommandLineJobRunner (le fameux tableau de chaines de caracteres fournis a toute 
methode main). Le premier correspond au chemin du fichier de contexte Spring contenant 
l'ensemble des parametres du batch (©). 

II est possible d'utiliser la syntaxe correspondant a la notion de Resource de Spring. Le fichier 
indique doit etre autonome, mais il peut bien sur importer d'autres fichiers Spring. II doit 
contenir la definition du job a lancer, mais aussi 1' infrastructure de Spring Batch (depot de job, 
lanceur et leurs dependances). Le deuxieme parametre correspond au nom du job a lancer 
Q), c'est-a-dire au nom du Bean definissant le Job. 

Nous avons parle en debut de chapitre de Fimportance de l'identite d'une instance de job, qui 
passe par la definition de parametres de job. Le CommandeLineJobRunner accepte des parame- 
tres supplementaires, apres le nom du job, qui sont utilises pour preciser les JobParameters qui 
definiront completement Finstance de job : 

java -cp "./lib/main/*" 

org. springframework. batch. core. launch. support. 

CommandLineJobRunner 
cl asspath: /tudu/batch/taskl et/Hel 1 oTaskl etTest -context. xml 
hel 1 oJob 

date.lancement=20081204<— Q 

Les parametres de job sont done a passer apres le nom du job, separes par des espaces, sous la 
forme nomParametre=valeurParametre. Nous passons dans notre exemple le parametre 
date. lancement avec la valeur 20081204 (Q). 
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Lors de nos premiers pas avec Spring Batch, nous avons lance notre batch de facon program- 
matique, avec une instance de JobParameters vide. Le parametre passe dans la ligne de 
commande precedente se traduirait en Java de la maniere suivante : 

Map<String, JobParameter> map = 

new HashMap<String, JobParameterX ) ; 
map. put ( "date. 1 ancement" .new JobParameter( "20081204" ) ) ; 
JobParameters params - new JobParameters(map) ; 
JobExecution jobExecution = launcher. run(job, params); 

Les parametres du job sont extremement importants pour definir avec precision 1' instance de 
job, dans le cas ou toutes les executions sont persistees par le JobRepository. Cela permet 
d'effectuer de facon fiable la reprise sur erreur. Nous verrons plus en detail la persistance des 
executions et la reprise sur erreur par la suite. 

Nous venons de voir le lancement d'un batch en ligne de commande, qui fonctionne de 
maniere synchrone, c'est-a-dire que le processus lance par le systeme d' exploitation attend la 
fin de F execution du batch. Cela est du au fait que le batch est execute dans le meme fil 
d'execution que le programme main. En d'autres termes, la fin de la methode main ne survient 
qu'apres la fin du batch. Cela ne pose aucun probleme pour ce type de lancement, mais 
certains autres modes de lancement par impulsion ne sont pas compatibles avec ce fonction- 
nement synchrone. 

Dans le cas ou un batch est lance avec une requete HTTP (car l'environnement de batch est 
contenu dans une application Web), le fonctionnement synchrone implique qu'aucune 
reponse ne sera renvoyee avant la fin du batch, ce qui peut etre tres long. Le fil d'execution de 
la requete HTTP est done mobilise par le batch. 

Certains conteneurs Web surveillent les fils d'execution qu'ils allouent aux requetes HTTP et 
tentent de les arreter s'ils sont mobilises depuis trop longtemps. II est done preferable de ne 
pas utiliser le mode synchrone et de demander a Spring Batch de lancer ses jobs dans des fils 
d'execution differents de celui du code appelant. 

Cela se parametre avec la propriete taskExecutor du SimpleJobLauncher : 

<bean id=" jobLauncher" 

cl a s s=" org. springf ramework. batch. core. launch. support. 
Simpl eJobl_auncher"> 
<property name="jobRepository" ref="jobRepository" /> 
<property name-"taskExecutor"> 
<bean 

cl as s=" org. springf ramework. core. task. Simpl eAsyncTaskExecut or" /> 
</property> 

</bean> 

Spring propose la notion de TaskExecutor, identique a celle introduite dans Java 5, qui permet 
de decoupler une tache et son mode de lancement. Par defaut, le Simpl eJobLauncher utilise un 
gestionnaire d'execution synchrone, mais nous parametrons explicitement dans notre exemple 
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un gestionnaire d' execution asynchrone, qui fait que le job est appele dans un fil d' execution 
dedie. 

Ce mode de fonctionnement est particulierement adapte pour les batch lances via une requete 
HTTP afin d'eviter de mobiliser des fils d'execution destines aux requetes HTTP. 



Notions avancees 

Cette section aborde des concepts qui, bien qu'avances, constituent une reelle plus-value de 
Spring Batch. 

Nous verrons notamment Fhistorisation, qui pennet de persister F execution des batch, les 
possibilites de reagir au cycle de vie d'un batch, ainsi que la possibilite de gerer la cinemati- 
que d'un batch. Nous finirons par la gestion des transactions et la gestion des erreurs, qui 
permettent d'implementer des batch robustes et fiables. 



Historisation des batch 

Spring Batch permet Fhistorisation des batch grace a sa notion de JobRepository. L'historisa- 
tion a deux utilites principales. Elle permet, d'une part, le monitoring des batch, particuliere- 
ment important pour les equipes de production, et, d' autre part, la reprise des batch, principa- 
lement quand une erreur est survenue. 

L'historisation ne gere pas seulement les dates de lancement d'un job, mais aussi le contexte 
complet d'une execution. Ce contexte peut etre reconstitue pour l'execution suivante du job, 
dans le cas ou il aurait echoue precedemment. II est des lors possible de reprendre le batch 
exactement la ou une erreur est survenue. 

Nous verrons plus en detail la reprise sur erreur par la suite et nous concentrons dans cette 
section sur la configuration de l'historisation des batch en base de donnees. 

Configuration de l'historisation 

Spring Batch propose une unique implementation de JobReposi tory qui delegue la persistance 
des differentes entites d'une execution de batch a des DAO. 

Dans notre premier exemple de batch, nous avons utilise le mecanisme de persistance, ou les 
DAO stockent les donnees en memoire. Ce mecanisme est utile pour le developpement, pour 
les tests ou encore quand l'historisation des batch n'est pas necessaire. Nous allons mainte- 
nant voir la configuration du mecanisme de persistance en base de donnees, qui permet de 
stocker de fa?on permanente l'historique des batch. 

Voici un exemple de configuration : 

<bean id="dataSource" 

cl a ss=" org. springframework. jdbc. data source. 
Singl eConnectionDataSource"><— Q 
<property name="dri verCl assName" value="org.hsqldb. jdbcDriver" /> 
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<property name="url " value="jdbc:hsqldb:hsql : //l ocal host/tudu" /> 
<property name="username" value="sa" /> 
<property name="password" value="" /> 
<property name="suppressCl ose" value="true" /> 
</bean> 

<bean id=" trans act ionManager" 

class-" org. springf ramework. jdbc.datasource. 
Da taSourceTrans act ionManager" 
p:dataSource-ref="dataSource" /><— Q 

<batch: job-repository<— Q 
id="jobRepository" 
data-source="dataSource"<— Q 
t r ansa cti on -manager=" trans act i onManager" /><— Q 

Puisque nous allons persiste l'historique des batch en base de donnees, nous definissons la 
connexion a la base de donnees via une DataSource (©). Cette source de donnees peut aussi 
etre utilisee par les composants du job (IteamReader, IteamWriter et objets d'acces aux 
donnees de l'application) s'ils travaillent sur la meme base de donnees. De plus, si les batch 
sont lances en ligne de commande, 1' execution de leurs etapes est sequentielle et ne survient 
que dans un fil d' execution. II n'y a done pas d'interet a utiliser un pool de connexions, qui 
peut creer des connexions inutilement (selon sa nature et sa configuration), et e'est pourquoi 
nous utilisons 1' implementation SingleConnectionDataSource, qui ne cree qu'une connexion, 
ce qui est parfaitement adapte pour ce genre de batch. 

Nous definissons ensuite le gestionnaire de transactions (Q) issu de Spring, qui necessite une 
reference a la source de donnees. La definition du JobRepository vient en dernier, en utilisant 
la balise job-repository du schema batch (©). Cette balise necessite une reference a la 
source de donnees et au gestionnaire de transactions pour fonctionner (Q, ©). 

Le script SQL pour generer les differentes tables utilisees par Spring Batch est disponible a la 
racine de l'archive Java de Spring Batch Core. II existe une version du script pour chacune des 
bases de donnees supportees par Spring Batch. 

Contenu de I'historisation 

Lhistorisation de Spring Batch consiste en la sauvegarde des elements suivants : 

• instances de job 

• parametres des instances de job 

• executions des instances de job 

• contexte de chacune des executions 

• etapes des executions 

• contexte de chacune des etapes 

La figure 15-4 illustre les cardinalites entre les differents elements de I'historisation. 
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Figure 15-4 
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Pour chaque execution d'un job, Spring Batch persiste l'ensemble de ces elements, et ce de 
facon transparente. Nous avons deja vu que les parametres d'un job definissent Fidentite de 
l'instance de ce job et avons pris pour exemple un batch lance quotidiennement, dont Fiden- 
tite est definie par la date du jour. En lancant un batch en ligne de commande, les parametres 
de l'instance peuvent etre precises a la fin de la ligne. Le programmateur charge de lancer les 
batch gere generalement F aspect dynamique de ces parametres. 

De facon programmatique, les parametres peuvent etre precises de la maniere suivante : 

Map<String, JobParameter> map = 

new HashMap<String, JobParameterX ) ; 
map. put ( "date . I ancement" ,new JobParameter( "20081204" ) ) ; 
JobParameters params - new JobParameters(map) ; 
JobExecution jobExecution = launcher. run(job, params); 

S'il s'agit du premier lancement du job du 4 decembre 2008, cette sequence provoquera Finsertion 
des elements suivants : l'instance de job, le parametre correspondant, l'execution de l'instance, le 
contexte correspondant. Le contenu du contexte de l'execution, des executions des etapes et de leur 
contexte correspondant est completement dependant du deroulement de l'execution. 

Interactions avec I'historisation 

II est possible d'interagir avec les donnees d'historisation d'un batch afin de lire et d'ecrire des 
donnees. 

Dans F implementation d'une Tasklet, un objet StepContribution est mis a disposition: il 
propose un ensemble de methodes permettant de tracer le deroulement de la Taskl et. 

En voici un exemple d'utilisation d'une de ces methodes : 

public RepeatStatus execute(StepContribution StepContribution, 
ChunkContext chunkContext) throws Exception { 
for(...) { // boucle d' execution 
(...) 

StepContribution . increment ReadCount( ) ; 

} 

return RepeatStatus. FINISHED; 

} 
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Toutes ces informations (nombre de lectures, d'ecritures, etc.) sont ensuite disponibles dans 
les colonnes de la table contenant les executions des etapes. Elles sont particulierement utiles 
pour savoir en un coup d'ceil combien d'elements ont pu etre traites. Dans le cadre de Futili- 
sation classique de Spring Batch, c'est-a-dire le schema lecture-transformation-ecriture regi 
par une etape fournie par les balises step et tasklet, la gestion de ces informations est effec- 
tuee automatiquement. 

La figure 15-5 illustre des informations disponibles suite a l'execution d'un job compoitant 
trois etapes. 

select CTrP_l^niTtONjn,CTrP_NAMr,rOMMTT_r01INT,RrAD_rOUNT,WRTTr_r01INT,n(IT_ror)r rrom rwtrh_"*ep_exenihon 
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Figure 15-5 

Informations de l'execution d'une etape 

La contribution a une etape (StepContribution) permet d'interagir avec un ensemble de 
donnees fini, mais il est parfois necessaire de stocker ses propres donnees. Pour adresser ce 
besoin, chaque etape dispose d'un contexte d'execution qui lui est propre, dans lequel il est 
possible de stocker des paires cle/valeur. 

Pour acceder a ce contexte, une Tasklet doit implementer l'interface StepExecut ion Listener : 

public class StorelnContextTaskl et implements 
Taskl et , StepExecut i on Listener { 



private StepExecution stepExecution; 



public RepeatStatus execute(StepContribution StepContribution, 
ChunkContext chunkContext) throws Exception { 

// execution 
(...) 

stepExecution .get ExecutionContext( ) . putString( 
"1 ast . i tern. handl ed" , 1 as 1 1 tern 
); 

return RepeatStatus. COMPLETED; 



public ExitStatus afterStep(StepExecution stepExecution) { 
return stepExecution. getExitStatus( ) ; 



public void beforeStep(StepExecution stepExecution) { 
this .stepExecution = stepExecution; 
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Cette interface definit deux methodes permettant de reagir a l'execution de l'etape. La 
methode correspondant au debut de l'etape permet de stocker une reference a 1' instance de 
StepExecution et done d'acceder au contexte de l'execution, a des fins de recuperation ou de 
stockage de donnees. 

Dans le cadre d'une etape utilisant le schema lecture -transformation-ecriture, FltemReader et 
1' ItemWri ter peuvent aussi beneficier d'un acces au contexte d'execution de l'etape, en imple- 
mentant 1' interface ItemStream. 

En voici un exemple pour un ItemReader (le principe est exactement le meme pour un 
ItemWriter) : 

public class JobRepoItemReader 

implements ItemReader<Todo>, ItemStream { 

private Todo lastTodo; 

public Todo readO 

throws Exception, UnexpectedlnputException.ParseException { 
Todo currentTodo = . . . ; 
if (currentTodo != null) { 

lastTodo = currentTodo; 

} 

return currentTodo; 

} 

public void update( Executi onContext executionContext) 
throws ItemStreamException { 
ifdastTodo != null ) { 
executionContext . put St ring ( 
"1 ast. todo. read" , 1 astTodo. toString( ) 

); 

} 

} 

public void closeO 

throws ItemStreamException { } 

public void open(ExecutionContext ec) 
throws ItemStreamException { } 

} 

L'interface ItemStream definit un ensemble de methodes de rappel permettant de gerer tres 
efficacement la reprise sur erreur. Nous ne l'utilisons ici que pour stocker des informations sur 
le dernier enregistrement lu par notre ItemReader au moment de l'appel update, juste avant la 
persistance du contexte d'execution de l'etape. 
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En resume 

L'historisation de l'execution des batch fournie par Spring Batch est particulierement interes- 
sante pour les equipes de production, amenees a surveiller le bon deroulement des batch. Cette 
historisation est tres precise, car elle permet de gerer des donnees jusque dans l'execution des 
differentes etapes d'un job. Les mecanismes d'interaction avec elle sont tres utiles pour 
comprendre la reprise sur erreur proposee par Spring Batch. 



Interception de l'execution d'une etape 

Spring Batch propose d'enregistrer au niveau d'une etape differents types d'ecouteurs qui 
reagissent aux evenements de son cycle de vie. 

La configuration correspondante s'effectue avec la balise 1 1 steners au sein de la balise step : 

<batch :step id="importTodoLi sts"> 
<batch rtaskl et> 
<batch:chunk reader="reader" writer="writer" 

commit-interval-"10" /> 
<batch : 1 i steners> 

<batch: 1 i stener ref-"myStepl_istener"/> 
</batch:l isteners> 

</batch:tasklet> 
</batch : step> 

<bean id="myStepListener" class-"tudu. batch. MyStepLi stener" /> 

Ces ecouteurs permettent d'effectuer des operations diverses, comme de la journalisation ou 
meme de changer le statut de sorti d'une etape. Lecriture d'un intercepteur peut se faire en 
implementant une interface ou en apposant des annotations sur les methodes d'une classe. 

Le type d'ecouteur le plus simple est le StepExecutionLi stener, dont voici un exemple 
d'implementation de l'interface : 

package tudu. batch. interceptor; 

import org. springframework. batch. core. Exit Status ; 

import org.springf ramework. batch. core. StepExecuti on; 

import org.springf ramework. batch. core. StepExecuti on Li stener; 

public class SimpleStepExecutionListener 
implements StepExecutionListener { 

public void beforeStep(StepExecution stepExecution) { 
// action avant l'execution de 1 'etape 

} 

public ExitStatus afterStep(StepExecution stepExecution) { 
// action apres l'execution de 1 'etape 
if(someSpecificCondition) { 
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return new ExitStatusCSPECIFIC EXIT STATUS"); 
} else { 

return stepExecution.getExitStatus( ) ; 

} 

} 

} 

Dans cet exemple, suite a l'execution de l'etape, le statut de sortie est modifie si une certaine 
condition est remplie. Ce changement de statut peut permettre de router l'execution du job 
vers une etape specifique ( voir plus loin pour le controle duflot d'un job). 

Un StepExecutionListener peut aussi etre implemente avec les annotations @BeforeStep et 
@AfterStep : 

package tudu. batch. interceptor; 

import org. sp ri ngf ramework. batch. core. annotation. AfterStep; 
import org. sp r i ngf ramework. batch. core. annotation. BeforeStep; 

public class AnnotationStepExecutionListener { 

©BeforeStep 

publ i c void before( ) { 

// action avant l'execution de l'etape 

} 

©AfterStep 

publ ic void after( ) { 

// action apres l'execution de l'etape 

} 

} 

II est important de remarquer que les deux methodes annotees n'ont pas a respecter la signa- 
ture de Finterface StepExecutionListener. 

Le StepExecutionListener n'est pas le seul ecouteur disponible dans Spring Batch. Le 
tableau 15-1 recense les differents types d'ecouteurs, dont le principe de configuration est 
toujours le meme (declaration avec la balise 1 i stener et ecriture par implementation d'inter- 
face ou apposition d' annotations). 

Les interfaces sont issues du package org. springframework. batch. core et les annotations de 
org.spri ngf ramework. batch. core. annotation. 



Tableau 15-1. Types d'ecouteurs d'etape 



Type 


Interface 


Annotations 




Etape 


StepExecutionLi stener 


BeforeStep 
AfterStep 




Lot 


ChunkLi stener 


BeforeChunk 
AfterChunk 
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Tableau 15-1. Types d'ecouteurs d'etape (suite) 



Type 


Interface 


Annotations 


Lecture 


ItemReadListener 


BeforeRead 

AfterRead 

OnReadError 


Transformation 


ItemProcessLi stener 


BeforeProcess 

AfterProcess 

OnProcessError 


Ecriture 


ItemWriteListener 


BeforeWrite 

AfterWrite 

OnWriteError 


Saut 


SkipListener 


OnSkipInRead 

OnSkipInProcess 

OnSkipInltlrite 



Flot d'un job 

Dans Spring Batch, un job est decompose en etapes, dont il est possible de controler Fenchai- 
nement. 

Le scenario le plus simple est 1' execution sequentielle, dans laquelle les etapes s'executent les 
unes a la suite des autres : 

<batch: job id="sequential Flow"> 

<batch:step id="stepA" next="stepB" /> 

<batch:step id="stepB" next="stepC" /> 

<batch:step id="stepC" /> 
</batch: job> 

L'attribut next de la balise step permet de preciser Fetape suivante. Dans l'exemple ci-dessus, 
Fetape stepA s'executera en premier, puis viendra Fetape stepB et enfin Fetape stepC. En 
revanche, si une erreur survient dans Fetape stepA, le job complet echouera et Fetape stepB ne 
sera pas executee. 

Spring Batch propose aussi une execution conditionnelle, afin de choisir Fetape suivante selon 
le statut de sortie de Fetape courante. Cette fonctionnalite permet de composer des enchaine- 
ments complexes d' etapes, pour, par exemple, remedier au probleme d'arret brutal du job en 
cas d'erreur dans une etape. Elle se combine particulierement bien avec Futilisation d'ecouteurs 
d'etape, capable de changer le statut de sortie selon certaines conditions. 

L' execution conditionnelle se parametre avec la balise next dans step : 

<batch: job id=" conditional Flowl"> 
<batch:step id="stepA" > 

<batch:next on="FAILED" to="stepB" /> 

<batch:next on="*" to="stepC" /> 
</batch:step> 
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<batch:step id="stepB" /> 
<batch:step id="stepC" /> 
</batch: job> 

Dans l'exemple ci-dessus, si l'etape stepA s'acheve avec un statut de sortie FAILED, l'etape 
stepB sera executee. Cette etape peut, par exemple, correspondre a une notification de l'erreur 
par e-mail, un nettoyage des donnees ou toute autre action de reprise suite a l'erreur. Pour tout 
autre statut de sortie, c'est l'etape stepC qui est executee. 

Le caractere special * est utilise pour representer n'importe quel caractere, repete zero, une ou 
plusieurs fois. Spring Batch reconnait aussi le caractere special ?, representant une unique 
occurrence de n'importe quel caractere. Ainsi, m*t correspond aussi bien a « mot » qu'a 
« matelot » tandis que m?t ne correspond qu'a « mot ». 

Gestion des transactions 

II est possible avec Spring Batch d'obtenir des reglages transactionnels tres precis afin de 
fiabiliser les batch et d'optimiser leurs performances. 

Transaction au sein d'une etape 

Spring Batch gere les transactions au niveau d'une etape. Pour une etape fondee sur le schema 
lecture-transformation-ecriture, les reglages transactionnels se font sur la balise taskl et : 

<batch: step id="importTodol_i sts"> 
<batch:tasklet> 
<batch: chunk reader="todol_i stltemReader" 
wri ter="todoLi stltemWri ter" 
commit-interval="10" /><— Q 
<batch: transact ion -attributes 
i sol ation="REPEATABLE_READ" 
propagation="REQUIRED" timeout="30" /><— © 
</batch:tasklet> 
</batch:step> 

La balise XML transaction-attributes (Q) permet de regler les attributs transactionnels 
(propagation, isolation et time-out) des transactions qui vont etre ouvertes pendant l'etape. 
Lattribut commit-interval de chunk (Q) permet de regler le nombre d'elements ecrits pour 
chaque transaction. 

Nous avons vu que la lecture et la potentielle transformation se font element par element, mais 
l'ecriture peut se faire par lot. En effet, l'unique methode d'ltemWriter accepte une liste 
d'elements. La creation d'une transaction etant une operation couteuse, ce mecanisme permet 
de diminuer leur nombre. 

Transaction et historisation 



L'historisation des executions des batch peut se faire au sein d'une base de donnees. II est 
important en ce cas que les donnees d' historisation soient coherentes avec les donnees 
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manipulees dans les batch. En d'autres termes, au sein d'un batch, la portee des transactions 
s'etend jusqu'aux donnees d'historisation. 

Dans le cas le plus simple, les tables d'historisation des batch se trouvent dans la meme base 
de donnees que les tables applicatives. II suffit des lors d'utiliser un seul gestionnaire de tran- 
sactions sur la meme source de donnees. Dans le cas ou les tables d'historisation se trouvent 
dans une base de donnees differente, les transactions doivent etre etendues aux deux sources 
de donnees (base d'historisation et base applicative). Nous nous trouvons alors dans le cas de 
transactions distribuees, qui mettent en jeu JTA et le protocole XA. S'il s'agit d'une solution 
qui fonctionne, elle implique des reglages importants (la configuration d'un gestionnaire de 
transactions JTA, ainsi que des sources de donnees compatibles XA) et entraine invariable- 
ment des baisses de performances (les transactions XA garantissent une excellente coherence 
des donnees, mais ces garanties ont un prix). 

Pour des batch, qui manipulent generalement de grands volumes de donnees, la lenteur impli- 
quee par les transactions XA peut s'averer problematique. Des mecanismes internes aux bases 
de donnees permettent generalement de s'affranchir des transactions distribuees au profit des 
transactions natives. Pour Oracle, le mecanisme de synonyme permet, par exemple, d'appeler 
des objets d'une base de donnees a partir d'une autre base de donnees. Concretement, les 
requetes SQL sur ces objets sont exactement les merries que si l'objet se trouvait dans la base 
de donnees. II est aussi possible de nommer completement un objet, c'est-a-dire de le prefixer 
du nom de sa base (pour Oracle, on parle aussi de user). 

Spring Batch utilise un prefixe pour effectuer les requetes sur les bases d'historisation (par 
defaut, ce prefixe est batch_). Si les tables d'historisation se trouvent dans un autre schema, un 
autre user ou une autre base de donnees (les termes varient selon le type de base de donnees), 
ce prefixe peut tres bien contenir le lieu de localisation des tables. 

Le prefixe est precise lors de la declaration du depot de job : 

<batch: job -repository 

id=" jobReposi tory" data-source="dataSource" 
t r ansa ct i on -manage r=" trans act i onManager" 
table-prefix="BATCH.BATCH_" 

/> 

Lattribut table-prefix de la balise job-repository permet done, selon les types de base de 
donnees, d'utiliser des transactions natives, plus rapides que les transactions distribuees, 
meme si les tables d'historisation et les tables applicatives ne se trouvent pas dans la meme 
base de donnees. 

En resume 

Nous venons de voir les principes de base pour la gestion des transactions dans Spring Batch. 
Ces principes suffisent dans le cas de batch simples, qui echouent rarement, voire jamais, et ne 
necessitent pas de reprise suite a un echec. 

Nous allons voir quel support propose Spring Batch pour les batch ne pouvant se passer d'une 
gestion des erreurs fiable, robuste et parfois complexe. 
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Gestion des erreurs 

II arrive frequemment que le deroulement d'un batch ne se passe pas comme prevu. Les 
causes d'erreur peuvent etre nombreuses : une entree dans un flchier ne respecte pas le bon 
formatage ; les donnees recuperees d'un flchier ne peuvent etre inserees en base de donnees, 
car elles violent des contraintes d'integrite, etc. 

Spring Batch dispose de mecanismes tres perfectionnes permettant aux batch de reagir au 
mieux lorsqu'une erreur survient. Les cas d'eiTeur etant sans limite et les demarches a adopter 
propres au contexte d'une application, nous allons presenter seulement quelques cas parmi les 
plus courants. 

Le support que Spring Batch propose pour la gestion des erreurs se situe au niveau de l'etape 
et dans le cas d'etape de type lecture-ttansformation-ecriture. 

Redemarrage sur erreur 

Le comportement le plus drastique en cas d'erreur est l'arret complet du batch. On suppose 
que le batch ne peut prendre aucune initiative et doit done s'arreter. On peut diagnostiquer 
l'erreur, faire le necessaire {via une operation manuelle, par exemple), puis relancer le batch. 
Cependant la premiere execution du batch a pu realiser une partie du travail, et il serait inte- 
ressant que la deuxieme tentative reprenne exactement la ou l'erreur est survenue. 

Spring Batch permet de faire cela grace a l'historisation et aux composants de lecture/ecriture 
qu'il propose. 

Considerons le flchier CSV suivant, qui permet d'importer des TodoLi sts en base de donnees : 

1, Spring par la pratique, true, 2008-11-29 

2,Tudu Lists (a Spring appl i cati on) ,fal se, 2008-11-25 

3, Spring 3.0,2008-11-20 

4, Etudes de cas, true, 2008-12-09 

5, Piano, false, 2008-12-09 

II comporte une erreur a la troisieme ligne : il manque un champ de type booleen. II va nean- 
moins etre utilise par un Fl atFi 1 elteamReader qui va tenter de le lire et passer les TodoLi sts a 
1'ItemWriter correspondant. 

Nous pouvons tenter de lancer notre job : 

Map<String, JobParameter> map = 

new HashMap<String, JobParameterX ) ; 
map. put ( "date. 1 ancement" .new JobParameter( "20081204" ) ) ; 
JobParameters params - new JobParameters(map) ; 

JobExecution je = launcher. run(job, params); Assert. assertEquals( 
Exi tStatus . FAILED. get Exi tCode( ) , je. get Exit Status ( ) . getExi tCode( ) 

); 

Nous constatons que le batch, lance au sein d'un test unitaire JUnit, a retourne un code 
d'erreur d'echec. Cependant, comme nous avons pu le voir precedemment, Spring Batch a 
persiste l'ensemble des donnees concernant cette execution dans son historique. Le job ayant 
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echoue, il est possible d'essayer de le relancer (une instance de job completee ne peut etre 
relancee !). 

La possibilite de relancer un job est parametree avec Fattribut restartabl e de la balise job : 

<batch:job id="todol_istsReadRetryJob" restartable-"true"> 
<batch:step id="todoLi sts Read Retry St ep"> 
(...) 

</batch:step> 
</batch: job> 

Par defaut, la valeur de restartabl e est true, c'est-a-dire que tout job peut etre relance tant 
qu'il n'a pas ete complete. II est done possible de relancer notre job du 4decembre 2008 
(instance totalement determinee par le parametre date.lancement et sa valeur 20081204), une 
fois que le fichier CSV d' entree a ete corrige. Spring Batch peut alors reconstituer le contexte 
de sa derniere execution. 

Puisque nous utilisons un Fl atFi 1 eltemReader, qui est capable de persister son avancement, la 
lecture reprend exactement la ou elle s'etait arretee. Tous les ItemReaders que nous avons vus 
dans ce chapitre sont capables d'un tel redemarrage sur erreur. 

Saut sur erreur 

Une autre facon de reagir a une eiTeur peut consister a sauter (skip) l'element posant 
probleme. 

Si nous reprenons notre fichier CSV comportant une erreur de formatage a la troisieme ligne, 
nous pouvons considerer que cette erreur n'est pas dramatique et que le batch peut tout de 
meme continuer. Cela permet de ne pas penaliser un grand nombre d' elements lorsqu'un seul 
pose probleme. 

Le saut d'elements se configure au niveau de la balise taskl et : 

<batch:tasklet> 
<batch: chunk reader="todol_istFi 1 eltemReader" 

wri ter="todol_i stltemWri ter" commit-i interval -"10" 
skip-1 imit="10">^O 
<batch:skippable-exception-classes> org.springf ramework.batch.it em. 
Pa rse Except ion<— © 
</batch:ski ppabl e- except i on-cl asses> 
</batch:chunk> 
</batch:tasklet> 

II est possible de preciser une limite pour le nombre d'elements a sauter, avec l'attribut skip- 
limlt (Q). Passee cette limite, l'etape est consideree en echec, ce qui garantit un certain 
niveau de qualite au job. La balise skippable-exception-classes permet de parameter les 
exceptions qui sont tolerees pour provoquer un saut (Q). Dans le cas du fichier CSV, une 
exception de la famille de ParseException est lancee quand une ligne est incorrecte. C'est 
done bien pour ce cas que nous voulons sauter l'element. 
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Avec ce parametrage, le premier lancement de notre job n'echoue pas. En revanche, seules 
quatre TodoLists seront inserees en base de donnees. Si l'historisation nous permettra de 
savoir qu'un probleme est survenu (en regardant la colonne coiTespondant au nombre 
d' elements qui ont ete sautes en phase de lecture), il n'est pas directement possible de savoir 
exactement l'origine du probleme, si ce n'est en baissant le niveau de journalisation de Spring 
Batch. 

Le saut d'element nous fournit une bonne occasion d'illustrer le principe d'ecouteur dans une 
etape, atravers l'interface SkipListener. 

Voici un exemple d' implementation effectuant de la journalisation : 

public class LogSkipListener 

implements SkipListeneKTodoList, TodoList> { 

private static final Log LOG = LogFactory .getLog( 
LogSkipListener. class); 

public void onSkipInProcessdodoList tl , Throwable ex) { 
LOG.errorC'impossible de transformer la todolist #"+ 
tl .getListId()+" : "+ex.getMessage( ) ) ; 

} 

public void onSkipInReaddhrowable ex) { 

LOG.errorC'impossible de lire une ligne : "+ex. getMessage( ) ) ; ) 

public void onSkipInWritedodoList tl , Throwable ex) { 
LOG.errorC'impossible d'ecrire la todolist #"+ 
tl .getListId()+" : "+ex.getMessage( ) ) ; 

} 

} 

Nous remarquons qu'une methode de rappel est disponible pour les trois phases du classique 
schema lecture-transformation-ecriture. 

Un SkipListener est positionne de la facon suivante (au niveau d'une etape) : 

<batch:step id="ReadTodoLists"> 
<batch:tasklet (...) > 

(...) 

<batch:listeners> 

<batch : 1 i stener class="tudu. batch. retry. LogSkipListener" /> 
</batch:listeners> 

</batch:tasklet> 
</batch:step> 

Un SkipListener peut etre tres precis quant a la raison du saut d'un element et s'avere done 
tres utile pour diagnostiquer des erreurs. 
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Nouvelle tentative sur erreur 

Nous avons vu deux reactions possibles lorsqu'une erreur survient dans une etape : l'echec 
complet du job ou le saut de F element posant probleme. Ces comportements sont adaptes 
pour des exceptions dites deterministes, c'est-a-dire qui surviennent systematiquement. 
L' exception survenant lorsqu'une ligne du fichier CSV des TodoLists n'est pas formatee 
correctement est deterministe : elle sera lancee si nous repetons la lecture encore et encore. 
Certaines exceptions ne sont pas deterministes, a l'image des exceptions dues a des problemes 
de concurrence d'acces. 

Reprenons notre exemple de lecture de TodoLi sts a partir d'un fichier CSV. Si la phase d'ecri- 
ture correspondait a la mise a jour des TodoLists et pas a une simple insertion, il serait tout a 
fait possible qu'il y ait des problemes de verrou dans une application fortement 
concurrentielle : la TodoLi st a mettre a jour pouiTait etre verrouillee par un autre fil d' execu- 
tion qui effectuerait des operations dessus. Cependant, ce genre de verrou est transitoire et 
peut etre leve apres quelques millisecondes. C'est exactement dans ce genre de situation qu'il 
peut etre interessant d'effectuer une, voire plusieurs, nouvelles tentatives (retry). Dans notre 
exemple, cela revient a resoumettre a la mise a jour la TodoLi st verrouillee en base de 
donnees. 

Spring Batch propose un mecanisme permettant d'effectuer plusieurs essais quand certaines 
exceptions sont lancees. Voici comment configurer ce mecanisme : 

<batch :step id="TodoLi stsRetryStep"> 
<batch:tasklet> 
<batch : chunk 

reader="todoLi stFi 1 eltemReader" wri ter="todoLi stltemWri ter" 
commit-interval="10" 
retry-1 imit="3"<— Q 
skip-1 imit="l"><— Q 
<batch : retryabl e- except ion- cl asses> 

org. spri ngf ramework.dao. Deadl ockLoserDat a Access Except i on<— Q 
</batch : retryabl e- except ion- cl as ses> 
<batch : ski ppabl e- except ion- cl asses> 

org. spri ngf ramework.dao. Deadl ockLoserDat a Access Except i on<— Q 
</batch : ski ppabl e- except ion- cl as ses> 
</batch:chunk> 
</batch:tasklet> 
</batch : step> 

L'attribut retry-1 imit (0) permet d'indiquer a Spring Batch combien de fois reessayer avant 
d'abandonner. La balise retryable-exception-classes permet de specifier a Spring Batch la 
ou les exceptions pour lesquelles il doit effectuer de nouvelles tentatives (©). L' abandon se 
traduisant par le saut de F element, il est necessaire de parameter l'attribut skip-limit pour 
autoriser les sauts (Q), ainsi que de preciser la ou les exceptions provoquant le saut (©). 

Dans notre exemple, nous specifions une Deadl ockLoserDataAccessExcepti on, qui correspond 
au fait que notre transaction a provoque un verrou mortel et qu'elle a ete perdante dans sa 
resolution. 
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En resume 

Spring Batch propose un support puissant et parametrable pour la gestion d'erreurs survenant 
dans des batch. Grace a l'historisation, un batch en erreur peut etre relance et reprendre son 
traitement la oil il s'etait interrompu. 

II est aussi possible de parameter le saut d'elements susceptibles de provoquer systematique- 
ment des erreurs, afin de ne pas penaliser un batch complet pour seulement quelques elements 
incorrects. 

Dans le cas d'erreurs transitoires, frequentes pour les applications concurrentes, Spring Batch 
peut effectuer de nouvelles tentatives au sein d'une meme execution d'un batch. 



Conclusion 

Nous avons aborde dans ce chapitre les concepts essentiels de Spring Batch. Ce projet adopte 
la philosophie de Spring grace a son cote declaratif et sa gestion des problematiques techni- 
ques, afin de laisser le developpeur se concentrer sur les composants propres a son applica- 
tion. Spring Batch propose un cadre de travail grace aux differents concepts qu'il propose 
(job, etape, phases lecture-transformation-ecriture), qui permet au developpeur de structurer 
de maniere uniforme et coherente ses batch. 

Avec Spring Batch et ses classes de lecture et d'ecriture pour les supports de donnees les plus 
courants, un batch complet peut etre realise via de la configuration, sans ecrire une ligne de 
code Java. 

Spring Batch permet d'ecrire des batch tres robustes, car il propose des mecanismes a la fois 
puissants et souples pour la gestion des erreurs. Ces mecanismes sont fondes sur l'historisa- 
tion des executions des batch, la gestion des transactions et la possibility d' effectuer de 
nouvelles tentatives ou de sauter certains elements dans un batch. Cette souplesse permet 
d'implementer un large eventail de comportements, afin de s' adapter aux besoins de qualite 
inherents aux traitements batch. 

Nous ne pretendons pas avoir rendu compte dans ce chapitre de l'ensemble des fonctionnali- 
tes proposees par Spring Batch, qui sont tres etendues. Nous conseillons done vivement au 
lecteur interesse de consulter l'excellente documentation de reference de Spring Batch, ainsi 
que les nombreux exemples presents dans la distribution, afin de connaitre l'exhaustivite des 
possibilites de ce framework. 
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Spring en production 



Cette partie decrit la maniere dont le framework Spring utilise des technologies facilitant 
F execution des applications. Ces technologies reposent essentiellement sur OSGi, pour la 
modularisation des applications, et JMX, pour leur supervision. 

Le chapitre 16 detaille les apports de la technologie OSGi dans la mise en ceuvre des appli- 
cations d'entreprise. Cette technologie permet leur decoupage en composants isoles au 
niveau des chargeurs de classes et leur administration a chaud. Spring integre OSGi par le 
biais du sous-projet Spring Dynamic Modules. Ce dernier utilise Spring au sein de composants 
OSGi et interagit avec les differents elements de la technologie. 

Le chapitre 17 se penche sur Foutil dm Server, le serveur d' applications de nouvelle gene- 
ration fonde sur OSGi, Tomcat et Spring developpe par SpringSource. Loutil dm Server 
ameliore et facilite l'utilisation d'OSGi dans les applications Java EE au niveau du serveur. 
II est en outre particulierement leger en termes d' execution et simpline les developpements 
de ce type. 

Le chapitre 18 decrit la technologie JMX, qui offre un cadre generique pour superviser les 
applications. Nous detaillons le support de cette technologie par Spring et montrons 
comment il facilite sa mise en ceuvre en impactant au minimum le code des applications 
Java/Java EE. 
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Nous avons vu que le framework Spring offre une maniere interessante de structurer et d' orga- 
niser les applications Java EE. Malgre cela, plus les applications sont constituees d'un grand 
nombre de classes, plus leur maintenance et leur evolutivite deviennent problematiques. Une 
solution interessante a ce probleme consiste a coupler le framework Spring, pour developper 
et structurer les applications, avec une technologie de gestion des composants et de leurs 
dependances. C'est l'objectif d'OSGi. 

Legere et mature, cette technologie peut etre utilisee dans un processus Java. Ciblant tout 
d'abord des applications embarquees, elle a ete popularisee par l'environnement de develop- 
pement Eclipse, qui a fait le choix de Fintegrer dans son socle, par F intermediate du conte- 
neur Equinox, afin de gerer les greffons. Elle est desormais de plus en plus repandue dans la 
communaute Java, notamment pour les applications executees dans les serveurs d' applications 
Java EE. 

Nous allons tout d'abord expliquer les differents concepts et mecanismes de la technologie, 
puis nous detaillerons le positionnement et Fintegration de Spring dans cette architecture. 
Nous mettrons egalement Faccent sur la mise en ceuvre concrete d'OSGi dans les applications 
d'entreprise ainsi que sur les difficultes generees par le cloisonnement des chargeurs de classes de 
la technologie. 

La technologie OSGi 

Avant d'aborder Spring Dynamic Modules, nous allons passer en revue les concepts relatifs a 
la technologie OSGi, sur laquelle se fonde et dont tire parti le framework. Rappelons que ce 
dernier permet de structurer les applications Spring en composants, tout en favorisant la 
programmation orientee services, chaque composant integrant un conteneur Spring. 



Spring en production 

Partie V 



Concepts 

OSGi permet de mettre en ceuvre, d'une maniere legere et au sein d'une meme machine 
virtuelle Java, les concepts de programmation par composant et orientee services. II contiibue 
ainsi a la structuration, a la modularisation et a la gestion des dependances des applications et 
permet d'exposer leurs traitements publics par F intermediate de services. 

La programmation orientee composant adresse les limitations de la programmation orientee 
objet. Bien que cette derniere offre d'interessants mecanismes afin de modulariser les traite- 
ments et les rendre reutilisables, elle n' offre que peu de support a la mise en relation des clas- 
ses entre elles avec un couplage faible tout en gerant leurs dependances. Plus les traitements 
de 1' application augmentent et se complexifient, plus ces limitations sont visibles et penalisantes 
en termes de maintenabilite et d'evolutivite de 1' application. 

Cet aspect peut devenir tres vite problematique lors de la mise en ceuvre de reseaux complexes 
d'objets, qui se traduit souvent par des couplages forts entre objets, qui nuisent enormement a 
la reutilisabilite des traitements. 



Spring et la modularisation 

Le framework Spring offre d'interessants mecanismes pour combler les limitations de la programmation 
orientee objet. Le patron de conception « injection de dependances », utilise conjointement avec la 
programmation par interface, permet, par exemple, un couplage faible entre les differentes entites de 
I'application. Cela n'est toutefois pas suffisant pour les tres grosses applications, dans lesquelles les 
fichiers de configuration de Spring tendent a gonfler demesurement. Le decoupage en sous-applications, 
ou modules, devient des lors indispensable. 

Une bonne approche consiste a regrouper les traitements dans des modules integrant un contexte appli- 
cant Spring dedie, tout en permettant une interaction entre ces modules afin de construire I'application 
finale. 



La programmation orientee composant offre une solution a ces problemes en regroupant, de 
facon coherente, les traitements dans des entites propres — les composants — , tout en 
permettant de gerer leurs dependances a F execution. 

De leur cote, les composants rendent utilisables certains de leurs traitements par Finterme- 
diaire de services afin de les rendre utilisables par d'autres composants tout en masquant la 
maniere dont ils sont implemented. Seuls les contrats des services sont importants pour les 
utilisateurs des services. Un composant qui utilise un service est appele consommateur de 
services et un composant qui met ce service a disposition, un fournisseur de services. L'archi- 
tecture de I'application est des lors orientee services puisque le service correspond au point 
central de communication entre les composants. 

Les principaux avantages apportes par ces concepts sont la specialisation des developpements 
et la possibility de faire interagir des briques heterogenes. La productivity en est grandement 
amelioree puisque le composant peut facilement etre reutilise par plusieurs autres. La mise a 
jour et F administration de ce type d'application s'en trouvent d'autant plus facilitees qu'il est 
possible de travailler sur une de ses parties sans avoir a modifier le reste. 
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Leur principal inconvenient vient des efforts supplementaires qu'il faut fournir pour structurer 
et concevoir F application. 



Architecture d'OSGi 

Comme OSGi ciblait initialement les systemes et applications embarques, 1' architecture 
est particulierement legere puisque ces derniers comportent d'importantes contraintes, 
notamment en termes de puissance et de memoire disponible. De plus, comme un des 
objectifs de cette technologie est de pouvoir fonctionner sur des plates-formes heteroge- 
nes, OSGi a fait le choix de Java comme environnement d' execution, ce dernier etant 
portable. 

La technologie OSGi fournit la specification d'un conteneur dont les mecanismes de fonction- 
nement sont structures suivant 1' architecture decrite a la figure 16-1. Nous pouvons constater 
la simplicite de cette derniere en comparaison de celles des conteneurs Java EE. 



Figure 16-1 
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La premiere couche, dite Module, correspond aux fondations de la technologie. C'est cette 
derniere qui permet de gerer les composants et leurs dependances, au niveau aussi bien du 
chargement des classes que de la gestion de leurs visibilites et de leurs versions. Cette couche 
est fondamentale, car elle met en ceuvre le cloisonnement des chargeurs de classes et offre une 
isolation des composants. 

Dans ce contexte, chaque composant a la possibilite de maitriser finement les packages Java qu'il 
utilise et qu'il met a disposition, rien n'etant visible par defaut. C'est particulierement inteiessant 
en cas de versions de bibliotheques Java non compatibles dans un meme processus. 

La deuxieme couche, dite Cycle de vie, prend en charge les etats des composants supportes 
par le conteneur tout en se fondant sur les mecanismes de la premiere couche. Ces etats 
permettent de gerer de maniere optimale les dependances des composants ainsi que la mise a 
disposition de leurs traitements dans le conteneur. 
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Cette couche standardise egalement les differentes interfaces de programmation d'OSGi a des 
fins d' introspection du conteneur et d'interaction avec les composants contenus. 

La derniere couche, dite Services, offre la possibilite aux composants de mettre a disposition 
des traitements par l'intermediaire de services ail sein d'une meme machine virtuelle Java. Ce 
mecanisme se fonde sur de simples classes Java tout en preconisant la programmation par 
interface pour definir les contrats des services. Cela permet aux autres composants d'utiliser 
ces services sans avoir connaissance de leurs implementations. 



Les composants OSGi 

L'entite principale de la technologie OSGi est le composant. Ce dernier permet de regrouper 
aussi bien les traitements que les elements de configuration associes, ces derniers servant a le 
configurer au sein du conteneur qui l'execute. 



Caracteristiques et structure des composants 

La particularite d'OSGi est de se fonder entierement sur les entites et concepts de la technolo- 
gie Java. De ce fait, un composant OSGi n'est autre qu'un fichier jar, fichier dont la structure 
est specifiee par Java. Ce dernier contient done un ensemble de classes, ainsi que le fichier 
descripteur de deploiement MANIFEST.MF. 

Ce fichier peut etre enrichi de fichiers de ressources, tels que les classiques fichiers de proprie- 
tes et XML, et contenir des fichiers jar relatifs a des bibliotheques Java, ces dernieres etant 
utilisables en interne par le composant. 

La figure 16-2 illustre la structure et le contenu possible d'un composant OSGi. 



Figure 16-2 
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A l'instar de la plupart des entites Java EE, un composant OSGi ne peut etre execute de 
maniere autonome. II necessite F utilisation d'un conteneur, ce dernier ayant la responsabilite 
de les gerer et de les configurer. 
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Afin de parameter le comportement du composant, le fichier MANIFEST.MF est utilise en 
tant que descripteur de deploiement lors de l'installation du composant dans le conteneur. A 
cet effet, la specification OSGi a enrichi la liste des en-tetes utilisables en son sein pour ses 
besoins au niveau de la description des composants et de la gestion de leurs dependances. 

Le tableau 16-1 liste les principaux en-tetes d'OSGi et utilisables dans le fichier MANI- 
FEST.MF. 

Tableau 16-1. Principaux en-tetes OSGi utilisables dans le fichier MANIFEST.MF 



Etat 


Dp^rrintion 


RiinHI o - Mani f oQtUorci nn 

DUIIU 1 C II a r 1 1 1 CO UCl 5 IU1I 


Correspond a la version de fichier MANIFEST du cornposant. 


ESundl e- Symbol icName 


Specifie I'identifiant symbolique du composant. 


Bundl e-Name 


Specifie le nom du composant. 


Bundl e-Versi on 


Specifie la version du composant. 


Bundl e-DocURL 




Permet de preciser I'adresse de la documentation du composant. 


Bundl e-Category 


Specifie la categorie du composant. 


Import-Package 


Specifie les noms et les versions des packages utilises par le composant. 


Export-Package 


Specifie les noms et les versions des packages mis a disposition par le com- 
posant. 


Dynamic Import -Package 


Specifie les noms et les versions des packages utilises par le composant. Cet 
en-tete se difference de I mpo rt - Pa c kage par le fait qu'il n'est pas necessaire 
que les dependances soient presentes au demarrage du composant. II suffit 
juste qu'elles le soient au moment de I'execution. 


Bundl e-Nati veCode 


Specifie la liste des bibliotheques natives presentes dans le composant. 


Requi re-Bundl e 


Specifie les identifiants symboliques des composants necessaires au bon 
fonctionnement du composant. 


Bundl e-Acti vator 


Specifie le nom de la classe dont les traitements sont executes lors du demar- 
rage et de I'arret du composant. Cette classe doit etre presente dans le com- 
posant et implementer I'interface Bundl eActi vator. 


Bundl e-Cl asspath 


Specifie le classpath du composant. Par defaut, la valeur implicite correspond 



a « . » pour les classes du composant. II convient de ne pas I'oublier lorsque 
des bibliotheques sont specifiers explicitement. 



Nous allons maintenant detailler les relations entre les composants et les conteneurs OSGi, 
ainsi que la maniere de configurer un composant par 1' intermediate de ces differents en-tetes. 

Conteneurs OSGi et cycle de vie 

Afin de pouvoir utiliser les composants, la technologie OSGi specifie un conteneur ayant 
la responsabilite de les gerer. Ce dernier met en ceuvre differents etats en se fondant sur les 
principes d'un automate a etats finis decrivant les transitions possibles a partir de chaque 
etat. 
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Le tableau 16-2 decrit les differents etats par lesquels peut passer un composant. 



Tableau 16-2. Etats possibles des composants OSGi 



Bat 




Installs 


Etat dans lequel se trouve un composant juste apres avoir ete installe, la resolution 

Uco Ucfjcl lUdl loco II dydlll jjdb CIIOUIC cue IcallocC. 


Resolu 


Etat dans lequel se trouve un composant apres que la resolution des dependances a 
ete realisee avec succes. 


En cours de demarrage 


Etat dans lequel se trouve un composant lorsqu'il est en train d'etre demarre. II cor- 
respond a un etat transitoire entre les etats resolu et actif. 


Actif 


Le composant a ete demarre avec succes. II est alors visible et disponible pour etre 
utilise par les autres composants. 


En cours d'arret 


Etat dans lequel se trouve un composant lorsqu'il est en train d'etre arrete. II corres- 
pond a un etat transitoire entre les etats actif et resolu. 


Desinstalle 


Etat dans lequel se trouve un composant apres avoir ete desinstalle. 





Determination des erreurs 



Lutilisation des etats offre d'interessantes informations permettant de detecter et resoudre les erreurs de 
dependances entre composants. En effet, un composant sans erreur et utilisable est necessairement dans 
un etat actif, a I'exception des composants de type fragment restart dans un etat resolu. 
Les composants comportant des erreurs de resolution des dependances ne peuvent acceder a I'etat 
resolu et restent done dans I'etat installe. Cela se produit en cascade lorsqu'un composant en utilise un 
autre. En effet, lorsqu'un composant reste en etat installe, il ne met pas a disposition ses packages expor- 
ter dans le conteneur. 

Une fois ces composants detectes, toutes les facilites du conteneur peuvent etre utilisees afin de determiner 
pourquoi la dependance ne peut etre resolue. 



La figure 16-3 illustre les differents etats du cycle de vie des composants OSGi ainsi que les 
differentes transitions possibles entre eux. 

Divers conteneurs OSGi sont disponibles dans le monde de l'Open Source, le plus connu etant 
Equinox, associe a l'environnement de developpement Eclipse. Felix, du consortium Apache, 
et Knopflerfish en sont deux autres interessants. Tous trois offrent des outils d' administration 
du conteneur, en mode console ou Web, et peuvent etre utilises de maniere autonome aussi 
bien qu'embarquee dans des applications Java classiques. 

Le tableau 16-3 recapitule les principales informations relatives a ces trois conteneurs. 



Tableau 16-3. Principaux conteneurs OSGi Open Source 



Conteneur 


Mainteneur 


Adresse Web du projet 


Equinox 


Consortium Eclipse 


http://www. eclipse, org/equinox/ 


Knopflerfish 


Makewave 


http://www.knopflerfish.org/ 


Felix 


Consortium Apache 


http://felix.apache.org/ 
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Figure 16-3 
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Le deploiement de composants OSGi dans ces conteneurs est tres simple : il suffit de specifier 
le fichier jar correspondant. Par la suite, le conteneur permet de voir les composants deployes, 
ainsi que leurs etats, et eventuellement de les changer. 

La figure 16-4 illustre la maniere de lister les composants deployes dans le conteneur Equinox 
tout en affichant leurs etats respectifs en se fondant sur la commande ss (short status). 



Figure 16-4 
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dans un conteneur 
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osgi> i 

Framework is launched. 

iJ Sidle Bundle 

0 ACTIVE system.bundle_3.2.2.R32x_v20070118 

1 ACTIVE org . springf ramework . bundle . spring . beans_2. 5. 5 

2 ACTIVE org. spnngf ramework .bundle, osgi . extensions . annotations_l. 1 . 1 

3 ACTIVE com. springsource.net .sf .cglib_2. 1 .3 

4 ACTIVE tududatasourceosgil.0.0 

5 ACTIVE com. springsource.org. apache. commons. collections_3. 2.0 
b ACliVb org. springf ramework. bundle. spring. web_2.b.tj 

7 ACTIVE org. springf ramework. bundle. spring. webmvc_2. 5. 5 

9 ACTIVE com. cpnngcourcc . org. apache . commons. digcctcr_l . 8. O 

9 ACTIVE tudu.war_1.0.0 

10 ACTIVE org. springf ramework . osgi .catalina.start. osgi_l .0.0. SNAPSHOT 

11 ACTIVE jtaO.0.0 

12 ACTIVE com.spnngsource.org.aopalliance_1.0.0 

13 ACTIVE com.spnngsource.com.mchange.v2.c3p0_0.9.1.2 

Fragments=34 

14 ACTIVE org . springf ramework .bundle . spring . core_2. Zj. 3 

15 ACTIVE com.springsource.slf 4j .log4j_1.5.0 

lfi ACTTVF nrg . spn ngf rpmewnrk . nsgi -ratal i na . nsg-i _5. 73. ^NAP^HDT 

17 ACTIVE tudu_core_osgi_1.0.0 

18 ACTIVE com. springsource.org. aspectj . runtime_l. 6. 1 



Voyons maintenant comment OSGi permet la gestion des dependances entre composants au 
sein d'un conteneur de ce type. 
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Gestion des dependances entre les composants 

La gestion des dependances entre composants se realise tout d'abord au niveau des packages. 
En effet, chaque composant doit specifier les differents packages des composants tiers conte- 
nant les classes utilisees pour les traitements. Par defaut, un composant ne peut voir et utiliser 
que ses classes propres. Nous reviendrons plus loin sur le cloisonnement des composants 
impose par la technologie OSGi. 

Abordons tout d'abord la maniere de configurer les relations de dependances entre compo- 
sants par l'intermediaire du fichier MANIFEST.MF. Ce dernier permet de specifier les 
packages mis a disposition et ceux utilises par l'intermediaire principalement des directives 
Import-Package et Export-Package, ainsi que l'illustre la figure 16-5. 



Figure 16-5 
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Afin d'autoriser l'utilisation de classes de composants tiers, la directive Import- Package 
doit etre utilisee afin de preciser les packages les contenant. La valeur de l'en-tete corres- 
pond a une liste dont les valeurs sont separees par des virgules, comme dans le code ci- 
dessous : 

Import-Package: nom-packagel,nom-package2,nom-package3. . . 

Nous pouvons remarquer que la liaison entre composants est implicite et se fonde sur les 
packages mis a disposition. 



Relation directe avec un composant 

Avec l'en-tete Import - Package, il n'est pas necessaire de savoir quel est le composant mettant a dispo- 
sition un package. Une specification explicite d'un composant par un autre est neanmoins possible par 
l'intermediaire de l'en-tete Require -Bundle. Dansce cas, le composant nepeutfonctionnerquesi I'autre 
composant est present. 

Notons que l'utilisation de l'en-tete Import -Package reste neanmoins preferable dans laplupartdes cas. 
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Pour chaque element specifie, differents attributs et directives optionnels, recapitules au 
tableau 16-4, peuvent etre utilises. lis offrent la possibility de specifier finement les contrain- 
tes de mise a disposition du package. 



Tableau 16-4. Attributs et directives optionnels de l'en-tete Import-Package 



Directive optionnelle 


Description 


resolution 


Specifie le type de resolution du package. La valeur par defaut est mandatory, specifiant que la pre- 
sence de la dependance est necessaire. La valeur optional specifie que la dependance n'est 
necessaire que si elle est utilisee. 


version 


Specifie la version du package a utiliser. Une plage de versions peut eventuellement etre specifiee. 
Dans le cas ou le parametre n'est pas specifie, la derniere version est utilisee. 



Au niveau de la syntaxe, les attributs et directives peuvent eventuellement suffixer le nom du 
package par F intermediate de points-virgules. Chaque attribut est compose d'un nom et 
d'une valeur, ces derniers etant separes par l'operateur =. Chaque directive est composee des 
memes elements que precedemment, mais separes par l'operateur :=. Un attribut prend part dans 
la determination de la correspondance entre les elements importes et exportes, tandis qu'une 
directive permet d' adapter le traitement d'un en-tete. Les attributs versi on et bundl e-versi on sont 
normalises par OSGi et permettent de specifier 1' information relative a une version. 

Le code suivant illustre la maniere d'ajouter des directives pour un package nomme nom-packagel : 

Import-Package: 

nom-packagel;directivel:=valeurl;directive2:-valeur2, . . . 
directive2:-valeur2; attributl-valeur3 

Un exemple concret d'utilisation de la directive Import-Package tire du fichier spring- 
beans.jar de Spring est partiellement retranscrit ci-dessous : 

Import-Package: 

javax.xml .parsers;resolution:=optional .net.sf .cglib. proxy; 
resol uti on: -optional , org. apache. commons . logging, org. springf ramewo 
rk. beans; resol uti on :=optional ;version=2. 5.0, org. springf ramewo 
rk. beans. annotation;resolution:=optional ;version=2.5.0, . . . 

Un en-tete supplementaire, appele Dynamiclmport- Package, est disponible. II differe du prece- 
dent par le moment de la resolution des dependances. Dans ce cas, cette resolution est realisee 
au niveau du chargement des classes, alors que precedemment cette resolution se faisait juste 
apres 1' installation du composant et avant sa mise a disposition dans le conteneur. Le cycle de 
vie d'un composant OSGi est detaille a la section « Composant OSGi » de ce chapitre. 

De la meme maniere, un composant doit specifier les packages qu'il desire rendre visibles 
pour les autres afin qu'ils puissent etre utilises. L'en-tete Export-Package permet de specifier 
la liste complete de ces packages, la syntaxe etant identique a celle de l'en-tete Import- 
Package, comme dans le code suivant : 

Export-Package: nom-packagel, nom-package2,nom-package3. . . 
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Pour chaque element specifie, differentes attributs et directives optionnels, recapitules au 
tableau 16-5, peuvent etre utilises. lis offrent la possibilite de specifier finement les contraintes de 
mise a disposition du package. 



Tableau 16-5. Attributs et directives optionnels de I'en-tete Export-Package 



Directive optionnelle 


Description 


uses 


Specifie la liste des packages utilises par le package exporte. 


mandatory 


Specifie une liste de parametres obligatoires a specifier lors de ('importation du pac- 
kage exporte. 


incl ude 


Specifie une liste de packages devant etre visibles par le composant important le 
package. 


excl ude 


Specifie une liste de packages devant etre invisibles par le composant important le 
package. 


version 


Specifie la version avec laquelle est mis a disposition le package. 



Comme precedemment, ces attributs et directives peuvent eventuellement suffixer le nom du 
package par F intermediate d'un point- virgule. Le code suivant illustre la maniere d'ajouter 
des parametres pour le package nomme nom-packagel : 

Export-Package: 

nom-packagel ;di recti vel-valeurl; 

Un exemple concret d'utilisation de l'en-tete Export -Package tire du fichier spring-beans.jar 
de Spring est partiellement retranscrit ci-dessous : 

Export-Package: 

org.springf ramework. beans. f actory.se rvi eel oader; uses: = 
"org.springframework.util .org.springf ramework. beans . factory. conf 
ig, org.springf ramework. beans. factory" ;version-2.5.5,org.springfr 
amewor k. bean s.annotat ion; uses :=" org.springframework.util .org.spr 
ingframework.beans";version-2.5.5. . . . 

Mecanismes de chargement des classes 

Une des particularites d'OSGi tient a sa maniere de gerer le chargement des classes Java grace 
a un mecanisme permettant de cloisonner les classes presentes dans les composants. Ce meca- 
nisme est si strict que ces classes ne sont meme pas visibles par introspection. 

Un des grands avantages de cette fonctionnalite vient de la possibilite d'utiliser, dans diffe- 
rents composants de versions differentes, voire incompatibles, de frameworks et de bibliothe- 
ques Java, les composants possedant leur classpath propre enrichi de celui de leurs dependances 
pour des versions donnees. 

En pratique, ce mecanisme est F aspect le plus deroutant d'OSGi, par rapport aux applications 
Java classiques. En revanche, les developpeurs de greffons pour l'outil Eclipse ne seront pas 
depayses puisque le cloisonnement y est present du fait de l'utilisation d'OSGi. 
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Un des aspects cles de cette technologie consiste en la comprehension de la resolution des 
classes. Son principe general reside dans la delegation de chargeurs de classes. Derriere cette 
designation obscure, OSGi met en ceuvre un chargeur de classes par composant, le chargeur 
etant en relation avec les chargeurs de classes des composants dependants. Ainsi, lorsque le 
composant tente de resoudre un nom de classe, le chargeur de classes du composant regarde 
tout d'abord si elle fait partie du composant courant. Si tel n'est pas le cas, il recherche si le 
package de la classe est present dans les dependances configurees. Si tel est le cas, il passe la 
main au chargeur de la dependance correspondant afin de charger la classe. Dans le cas 
contraire, une exception de type CI assNotFoundException est levee pour signifier que la classe 
ne peut etre resolue. 

La figure 16-6 illustre la resolution d'une classe presente dans une dependance d'un 
composant. 



Figure 16-6 
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Le principal effet de bord de ce mecanisme de chargement de classes est consecutif a 
l'utilisation du chargement dynamique de classes avec l'instruction Class.forName. 
D'une maniere generale, il est recommande d'utiliser dans le contexte d'OSGi la 
methode 1 oadCl ass du chargeur de classes souhaite. Bien que cela puisse paraitre anecdo- 
tique, c'est une des principales raisons pour lesquelles un framework ou une bibliotheque 
Java ne peuvent etre utilises dans un conteneur OSGi. C'est notamment le cas des biblio- 
theques utilisant la classe DriverManager de JDBC et du framework Commons Logging 
heberge par Apache. Ce dernier correspond a un meta-framework servant d'aiguillage 
vers un framework de traces applicatives cible dont les traitements d' initialisation se 
fondent sur la clause Class.forName en utilisant les informations contenues dans un 
fichier de proprietes. 

Pour cette bibliotheque, il est recommande d'utiliser un framework de traces applicatives tel 
que SLF4J, lequel ne contient pas tous les problemes de chargement de classes de Commons 
Logging et est de plus utilise en interne par Spring Dynamic Modules. 
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Interaction avec le conteneur 

Comme nous l'avons evoque precedemment, les composants OSGi doivent fonctionner dans 
un conteneur afin de beneficier de tous les principes decrits dans ce chapitre. Bien que la 
majorite des traitements des composants n'ait pas connaissance du conteneur, la specification 
OSGi propose un ensemble d'interfaces de programmation afin d'interagir avec lui et de 
manipuler les entites qu'il contient. 

Cette section decrit les principales entites de la specification OSGi. 
Activation 

La technologie OSGi offre la possibilite de specifier une entite d' activation pour un compo- 
sant par F intermediate de Fen-tete Bundl e- Activator du fichier MANIFEST.MF. La valeur 
specifiee doit correspondre au nom de la classe implementant Finterface BundleActivator 
pour le composant. 

Cette fonctionnalite offre la possibilite de specifier des traitements aussi bien au demarrage 
qu'a Farret des composants tout en mettant a disposition F entite relative au contexte d'execution, 
entite permettant d'interagir avec le conteneur OSGi (voir la section suivante). 

De ce fait, Finterface possede deux methodes, start et stop, qui permettent de gerer ces deux 
evenements, comme Fillustre le code suivant : 

public interface BundleActivator { 

//Appel lors du demarrage du composant 
void start(BundleContext context); 

//Appel lors de 1 'arret du composant 
void stop(BundleContext context); 

) 

La mise en ceuvre d'une entite d' activation permettant de tracer le demarrage (Q) et Farret 
(©) d'un composant se realise par Fintermediaire d'une implementation de la classe prece- 
dente de la maniere suivante : 

public class SimpleTraceBundleActivator 

implements BundleActivator { 

public void start(BundleContext context) {<— O 
System. out. printlnCDemarrage du composant"); 

} 

public void stop(BundleContext context) {<— Q 
System. out. printlnC'Arret du composant"); 

} 

} 
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Afin que cette classe soit appelee par le conteneur au niveau des phases de demarrage et 
d' arret du composant, la valeur suivante doit etre specifiee dans le fichier MANIFEST.MF en 
tant que valeur de l'en-tete Bundle -Activator : 

Bundl e- Activator: Simpl eTraceBundl eActi vator 

Nous allons voir comment exploiter Finstance relative au contexte d'execution, entite passee 
par le conteneur en parametre des methodes start et stop precedemment decrites. 

Contexte d'execution 

Nous avons vu que 1' interface correspondant au contexte d'execution peut etre recuperee au 
niveau de l'entite d'activation d'un composant OSGi, cette interface etant fournie lors du 
demarrage et de 1' arret du composant. 

Ce contexte constitue le point d' acces vers les autres entites de la specification afin d'interagir 
avec le conteneur. Le tableau 16-6 recapitule les differentes fonctionnalites offertes. 



Tableau 16-6. Fonctionnalites offertes par le contexte d'execution OSGi 



Fonctionnalite 


Description 


Observation des evenements 
du conteneur 


Offre la possibilite de gerer des observateurs relatifs aux evenements 
publies par le conteneur. Cela permet de mettre en oeuvre des patrons de 
conception tels que extender (voir la section « Concepts avances »). 


Enregistrement de services 


Permet d'enregistrer des implementations de services (voir la section 
« Services »). 


Recuperation et utilisation 
d'instances de services 


Permet d'acceder a des instances de services afin d'executer leurs 
methodes (voir la section « Services »). 


Manipulation de composants et recupe- 
ration d'instances de composants 


Offre la possibilite de gerer des composants dans le conteneur et d'avoir 
acces a leurs instances. Cela peut s'utiliser aussi bien pour installer des 
composants, recuperer la liste complete des composants presents dans 
le conteneur ou gerer leur cycle de vie. 


Interaction avec la zone persistante de 
stockage 


Permet de creer des fichiers dans la zone de stockage persistante mise 
a disposition par le conteneur OSGi. 



Une fonctionnalite importante d'OSGi est la mise en ceuvre et Futilisation des services (voir 
la section suivante). Nous nous concentrons ici sur les autres fonctionnalites importantes 
decrites au tableau 16-6. 

Le contexte d'execution permet d'introspecter le contenu du conteneur afin d'avoir acces a 
des informations concernant les composants deployes dans le conteneur. A cet effet, les 
methodes getBundles (©) et getBundle (©) peuvent etre utilisees avec l'interface Bundle, 
comme le montre le code suivant : 

Bundl eContext contexte = (...) 

//Recuperation des composants presents dans le conteneur 
Bundle[] composants = contexte. getBundles( ) ;<— © 
//Recuperation du composant d'identifiant 14 
Bundle composant = contexte. getBundl e( 14) ;<— © 
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II est egalement possible d' installer un composant par F intermediate des methodes 
install Bundle, comme dans le code suivant : 

//Installation du composant correspondent a un fichier jar 
Bundle composant = contexte.installBundle( 

"f i 1 e: ///devel oppement/osgi /mon- composant . jar" ) ; 

L' interface Bundle est particulierement interessante. Comme le montre le code suivant, elle 
offre la possibilite de recuperer des informations et les metadonnees associees (©), de gerer 
le cycle de vie d'un composant (©), d'interagir avec lui afin de charger des classes (©) et 
d'avoir acces a des ressources (©) : 

Bundl e bundl e = (...) 

//Recuperation de 1 'identifiant et du nom symbolique du composant 
long identifiant = bundle. getBundleId( ) ;<— © 
String nomSymbol ique - bundl e.getSymbol icName( ) ;<— © 
//Recuperation des en-tetes presents dans le fichier 
//MANIFEST. MF 

Dictionnary entetesManifest = bundle. getHeaders( ) ;<— © 
//Demarrage du composant s'il est dans l'etat resolu 
int etat = bundl e. getState( ) ;<— © 
if ( eta t==Bundl e. RESOLVED) { 
bundl e. start( ) ;<— © 

} 

//Chargement d'une classe 

Class classe = bundl e. 1 oadCl ass( "monpackage.MaCl asse" ) ;<—© 
//Recuperation d'une ressource 

URL urlRessource = bundl e.getResource( "monFi chier.txt" ) ;<— © 

Une autre fonctionnalite interessante fournie par le contexte d'execution consiste en la mise 
en ceuvre d'observateurs d'evenements publies par le conteneur. Le tableau 16-7 recapitule 
ces differents types d'evenements. 



Tableau 16-7. Types d'evenements publies par le conteneur OSGi 



Type d'evenement 


Description 


Au niveau des composants 


Correspond aux changements d'etats des composants. 


Au niveau du conteneur 


Correspond a des evenements relatifs au demarrage du conteneur, a des messa- 
ges d'information, d'avertissement ou d'erreur et a I'execution de la methode 
ref reshPackage de la classe PackageAdmin. 


Au niveau des services 




Correspond aux enregistrements, desenregistrements et modifications des servi- 
ces. 



Nous ne detaillons ici que l'utilisation des evenements au niveau des composants, l'utilisation 
des autres types etant similaire. Ce type d'evenement est particulierement interessant pour 
suivre les changements d'etats des composants dans le conteneur. Nous verrons plus loin dans 
ce chapitre qu'il sert de fondation a la mise en ceuvre du patron de conception extender. 
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Afin d'etre a l'ecoute des evenements, un observateur doit etre utilise. Dans notre cas, ce 
dernier doit implementer l'interface Bundl eListener, laquelle necessite la definition de la 
methode bundl eChanged afin de recevoir d'une maniere asynchrone l'evenement publie par 
l'intermediaire de la classe Bundl eEvent. 

Le code suivant illustre la mise en ceuvre d'un observateur (Q) afin de detecter le demarrage 
(Q) des composants presents dans le conteneur : 

Bundl eContext contexte = (...) 

contexte. addBundlel_istener(new Bundl e Li stener( ) {<— O 
public void bundleChanged(BundleEvent event) { 

if (event. getType( )==BundleEvent. STARTED) {<— Q 
System. out. printlnCComposant " + 

event .getBundl e( ) .getSymbol i cName( ) + " demarre."); 

} 

1 

}); 

La presence de l'interface SynchronousBundl eLi stener permet de realiser la meme fonctionna- 
lite, mais de maniere synchrone. 



Services 

La notion de service est une autre brique essentielle d'OSGi. Les services permettent de 
mutualiser ressources et traitements entre composants. lis offrent egalement la possibilite de 
mettre en ceuvre une approche orientee services simple, fondee sur les POJO et la programmation 
par interface. 

Dans cette section, nous allons voir comment creer et enregistrer des services crees avec cette 
technologie puis comment les utiliser. 

Manipulation 

La technologie de base ne supporte pas la configuration des services par l'intermediaire d'un 
fichier de proprietes ou XML, mais une brique additionnelle, appelee « Declarative 
Services », y remedie. 

La seule maniere de manipuler les services consiste a utiliser le contexte d'execution par 
l'intermediaire des methodes regi sterServi ce. Ces dernieres prennent en parametres le ou les 
noms d'enregistrement, l'instance du service ainsi qu'eventuellement des proprietes. 



Norn d'enregistrement 

Comme la mise en oeuvre des services utilise de preference la programmation par interface, il est 
recommande de specifier le nom de l'interface correspondant au contrat du service en tant que nom 
d'enregistrement. 
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Une instance de type ServiceRegi strati on est retournee, qui permet de desenregistrer le 
service. Une bonne pratique consiste a specifier des traitements d'enregistrement et de desen- 
registrement des services dans l'entite d'activation d'un composant. Cette approche offre la 
possibilite de desenregistrer correctement les services d'un composant lors de son arret, 
comme dans le code suivant : 

public class GestionServiceBundleActivator 

implements BundleActivator { 
private ServiceRegistration enregistrementService; 



Une fois un service enregistre, il peut etre utilise par n'importe quelle entite d'un composant en 
se fondant sur son instance, laquelle est recuperee par l'intermediaire du contexte d'execution. 

Utilisation 

Pour utiliser un service OSGi, il est necessaire d'avoir acces a l'instance specifiee lors de 
l'enregistrement de ce dernier. Cette recuperation se realise en deux etapes : 

• Acces a l'objet de type Servi ceRef erence coiTespondant au service ; 

• Acces a l'instance du service a partir de l'objet precedent. 

Comme l'illustre le code suivant, la premiere etape est mise en ceuvre par l'intermediaire des 
methodes getServiceRef erence (Q) et getServi ceReferences, ces deux methodes se fondant 
sur le nom du service en parametre : 

Bundl eContext contexte = (...) 

String nomService = "ContratMonService"; 
Servi ceRef erence servi ce Reference 

= contexte. getServi ceReference(nomServi ce) ;<— O 

L'instance servi ceRef erence peut etre gardee en memoire et utilisee par la suite ann de recu- 
perer une instance du service chaque fois que ce dernier doit etre utilise. 

Le code suivant montre la maniere de recuperer et d' utiliser un service par l'intermediaire de 
la methode getServi ce (Q) du contexte (cette methode se fonde sur l'instance de type 
Servi ceReference) : 




public void start(BundleContext context) { 

ContratMonService service = new MonServi ce( ) ; 

this. enregistrementService = context. registerService( 

"ContratMonService", service, null); 



public void stop(BundleContext context) { 
if (this.enregistrementService!-null ) { 

thi s .enregi strement Servi ce. un regis ter( ) ; 
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Bundl eContext contexte = (...) 
ServiceReference serviceReference = (...) 

//Recuperation de 1 'instance du service 
ContratMonService service 

= contexte. getService(serviceReference) © 
//Utilisation des methodes du service 
(...) 

//Liberation de 1 'instance du service 
contexte. unget Service (servi ceReference) ;<— Q 

Le contrat du service utilise doit etre visible au moyen d'une importation dans la configuration 
du composant. 

Comme vous avez pu le constater, la recuperation d'une instance d'un service OSGi se realise 
en deux etapes. Cela provient du caractere dynamique de la technologie. En effet, un service 
peut etre desenregistre alors que son utilisateur est toujours actif. De ce fait, il est possible de 
relacher l'instance du service utilisee ponctuellement par l'intermediaire de la methode 
ungetService (Q), l'instance servi ceReference restant elle-meme toujours active et utilisable 
lorsque le service doit etre a nouveau utilise. 



Concepts avarices 

Maintenant que nous avons vu les differents concepts relatifs a la technologie OSGi, nous 
allons aborder quelques bonnes pratiques et patrons de conception permettant d'ameliorer la 
qualite des developpements de ce type. 

Ces techniques sont elles-memes utilisees dans les frameworks afin d'ameliorer leurs traitements. 
Patron de conception extender 

L'objectif de ce patron de conception est de limiter l'usage des entites d'activation et services 
afin d' initialiser des traitements pour les composants tout en gardant une coherence 
globale. II se fonde sur l'usage des observateurs d'evenements des composants, observateurs 
dont la mise en ceuvre est decrite a la section « Contexte d' execution ». 

Un composant est dedie pour l'ecoute des changements d'etat des composants. Le nom de ce 
composant contient habituellement le mot-cle extender. Lorsqu'un composant est en cours 
d'activation ou devient active, le composant d' observation scrute le contenu du composant afin 
de detecter diverses metadonnees. Si ces dernieres sont presentes, il realise des traitements 
d' initialisation en chargeant differentes classes par l'intermediaire de son chargeur de classes. 

Les metadonnees sont principalement localisees dans les repertoires META-INF, OSGI-INF 
ou WEB-INF du composant. 

Ce principe presente l'avantage d'etre non intrusif pour les composants et de modulariser les 
mecanismes de chargement dans une entite unique. De plus, en utilisant ce patron, les compo- 
sants n'ont plus la necessite de specifier une entite d'activation par l'intermediaire de la direc- 
tive Bundle- Activator. 
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Nous verrons a la section relative a la mise en ceuvre de Spring Dynamic Modules que ce 
patron est utilise arm d'initialiser les contextes applicatifs de Spring dans les composants 
incluant un ou plusieurs fichiers de configuration utilisables par ce framework ou possedant 
un repertoire WEB-INF. 

Fragments 

Au travers d' applications OSGi, il est parfois necessaire d'etendre certains composants exis- 
tants fournis par des tiers afin notamment de les parameter. Les exemples classiques corres- 
pondent a la configuration des traces applicatives et des pilotes JDBC. 



Support des fragments dans les conteneurs OSGi 

A I'instar des conteneurs Equinox d'Eclipse et Knopflerfish, la plupart des conteneurs OSGi supportent 
cette fonctionnalite de la specification. Bien qu'etant un conteneur robuste et mature, le conteneur Felix ne 
met en ceuvre que partiellement cette fonctionnalite dans ses dernieres versions. 

La specification fournit a cet effet le concept defragment, compos ant particulier correspond a 
un composant OSGi classique, a deux exceptions pres : 

• II doit posseder l'en-tete Fragment -Host dans son fichier MANIFEST.MF afin de specifier 
le composant auquel il est rattache. 

• II possede un cycle de vie different des composants classiques et ne peut etre demarre. II 
reste dans Fetat resolu si aucune erreur ne s'est produite lors de la resolution de ses depen- 
dances. 

Comme un fragment est un composant particulier, tous les elements presents dans un compo- 
sant classique peuvent etre utilises. Le deploiement de ce type de composant se realise egale- 
ment de la meme maniere que les composants classiques. 

Soit un fragment norrrme org.springframework.osgi .log4j.config permettant de parameter 
le composant org.springframework.osgi .log4j.osgi correspondant a la bibliotheque de 
traces applicatives Log4J d' Apache. Pour specifier a Log4J un fichier log4j.properties 
permettant de configurer cet outil, il suffit de creer un fragment le contenant a sa racine. 

Pour preciser le composant auquel fait reference le fragment (Q) ainsi que les informations 
relatives au fragment (Q), la configuration de ce composant dans le fichier MANIFEST.MF 
est la suivante : 

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: Configuration Log4J<— Q 

Bundle- Symbol icName: org.springframework.osgi . log4j.config<— Q 
Bundle-Version: 1.0.0 

Fragment -Host: org .spri ngf ramework.osgi . 1 og4j .osgi 

bundl eversi on="l . 2. 13"<— Q 

Le fichier MANIFEST.MF aurait pu contenir un en-tete Import- Package si necessaire. 
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En resume 

En detaillant les differentes couches de F architecture OSGi, nous avons vu comment sont 
structures les composants et detaille leurs interactions ainsi que la maniere dont les conteneurs 
de ce type les gerent. 

En se fondant sur des elements de Java, OSGi propose une maniere simple et legere de mettre 
en ceuvre la programmation orientee composant et des architectures orientees services. 

En complement, differents services normalises sont specifies par OSGi arm de repondre plus 
precisement a une problematique technique particuliere. II existe de nombreux services de ce 
type, mais nous ne les decrirons pas ici, car ils ne sont pas essentiels pour la comprehension 
du fonctionnement de Spring Dynamic Modules. 

Spring Dynamic Modules 

Lors de la mise en ceuvre de composants OSGi, le developpeur a la possibilite de structurer les 
traitements en se fondant sur differents outils. Une bonne approche est cependant d'integrer 
Spring dans les composants afin de beneficier de tous les apports decrits aux chapitres prece- 
dents et dont les principaux sont Finjection de dependances et la programmation orientee 
aspect. 

C'est le principal atout de Spring Dynamic Modules que de se fonder sur les bonnes pratiques 
d'utilisation de la technologie OSGi. Dans le meme esprit que le framework Spring, l'outil 
offre la possibilite de realiser des traitements tels que Fenregistrement et le referencement par 
declaration tout en gerant de maniere optimale Faspect dynamique d'OSGi. 

Spring Dynamic Modules permet de realiser des composants OSGi, mais sans se lier explici- 
tement aux API de cette technologie et tout en gardant un cadre ouvert. II reste neanmoins 
possible d'y avoir acces pour les utiliser si necessaire. 

L'outil propose en outre un support Web afin de deployer tres facilement, dans des serveurs 
applicatifs tels que Jetty et Tomcat, des applications Web packagees sous forme de composants 
OSGi. 

Afin de permettre de mettre en ceuvre un maximum d' applications d'entreprise dans un envi- 
ronnement OSGi, un grand nombre de frameworks et bibliotheques Java EE sont fournis sous 
forme de composants OSGi. 

Frameworks et OSGi 

Lors de la mise en ceuvre d' applications d'entreprise avec Java EE, de nombreuses briques 
applicatives sont utilisees afin d'implementer les differentes fonctionnalites de ces applica- 
tions. Le developpement d' applications de ce type dans un conteneur OSGi ne deroge pas a 
cette regie. Par contre, si les fichiers de la distribution de Spring (a partir de la version 2.5) 
sont en eux-memes des composants OSGi, ce n'est pas le cas pour la plupart des bibliotheques 
ou frameworks Java EE. 
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Ann de contourner cette difficulte, plusieurs approches sont envisageables. La premiere 
consiste a utiliser des depots mettant a disposition des versions des fichiers jar de bibliotheques et 
de frameworks Java EE compatibles avec OSGi. 

Le tableau 16-8 dresse la liste des depots de composants OSGi presents sur Internet. 



Tableau 16-8. Depots de composants OSGi 



Depot 


Description 


SpringSource Repository 


Depot mis a disposition par la societe SpringSource et contenant la plupart 
des bibliotheques et frameworks utilises dans le developpement d'applica- 
tions Java EE. Un outil de recherche est propose en complement a I'adresse 
http://www. springsource. com/repository/app/. 


OSGi Bundle Repository (ORB) 


Depot heberge par I'OSGi Alliance. Un outil de recherche est propose a 
I'adresse http://www.osgi.org/Repository/HomePage. 


Eclipse Orbit 


Depot de composants OSGi d'Eclipse. Comme il est essentiellement utilise 
pour les developpements Eclipse, des en-tetes specifiques peuvent etre pre- 
sents dans le fichier MANIFEST.MF. Le depot est accessible a I'adresse 
http://www. eclipse, org/ orbit/. 


Apache Felix Commons 


Depot de composants rattache au projet Felix. II contient un ensemble de 
composants utilisables pour les developpements Java EE et est disponible 
a I'adresse http://felix.apache.org/site/apache-felix-commons.html. 


Apache Commons OSGi 

I 


Page resumant la liste des projets Commons d'Apache et proposant des 
distributions compatibles OSGi. La page recapitulative est disponible a 
I'adresse http://wiki.apache.org/commons/CommonsOsgi. 



Si un outil que Ton souhaite utiliser n'est pas present dans ces depots, une seconde approche 
consiste a creer une version OSGi des fichiers jar de la bibliotheque ou du framework consi- 
dere. Cette operation peut etre realisee manuellement, mais elle est fastidieuse. II est prefera- 
ble de recourir a un outil tel que Bnd afin de creer un fichier compatible. Cet outil est disponi- 
ble a I'adresse http://www.aqute.bi7/C0de/Bnd. 

L' outil Bnd correspond a un fichier jar qu'il est possible d'executer par 1' intermediate de la 
commande java -jar. Differentes options sont alors proposees, dont les principales sont les 
suivantes : 

• print pour afficher les valeurs des en-tetes OSGi standards pour le fichier jar en parametre ; 

• wrap pour construire automatiquement un fichier jar compatible OSGi a partir d'un fichier 
qui ne Test pas. 

Nous allons utiliser la seconde option afin de creer un fichier jar compatible OSGi pour le 
fichier jta- 1.0.1. jar, fichier contenant les interfaces Java EE relatives aux transactions distri- 
buees. 

Le code suivant decrit la commande a utiliser afin de creer un fichier jar compatible OSGi : 

java -jar bnd-0. 0.249. jar wrap jta -1 .0.1. jar 

II est possible de parametrer cette creation en se fondant sur un fichier dans lequel sont specifiees 
differentes proprietes, telles que la version ou des valeurs d' en-tetes. 



Spring Dynamic Modules 

Chapitre 16 



Le code suivant foumit un exemple de fichier de ce type : 
version=1.0.1 

Export -Package: javax.transaction*;version=${version} 
Bundle-Version: ${version} 
Bundle-Description: Jta 
Bundle-Name: jta 

L'utilisation du fichier ci-dessus se realise par le biais de l'option -properties de Bnd suivie 
de son nom, comme dans F exemple suivant : 

java -jar bnd-0. 0.249. jar wrap -properties jta. bnd jta. jar 



Mise en oeuvre 

Pour utiliser Spring Dynamic Modules, un conteneur OSGi est necessaire. Pour notre expose, 
nous allons nous fonder sur Equinox, ce dernier etant integre a l'outil de developpement 
Eclipse. Aucun element n'est toutefois specifique a ce conteneur. 



Developpement OSGi dans Eclipse 

Afin de realiser ce type de developpement dans Eclipse, une plate-forme cible doit etre creee afin de 
specifier les composants que le conteneur Equinox peut potentiellement utiliser lors de son demarrage. 
Les composants presents dans I'espace de travail peuvent egalement I'etre dans le conteneur. L'annexe B 
disponible sur le site Web dedie a I'ouvrage decrit le developpement OSGi avec cet outil. 



Le tableau 16-9 recapitule la liste minimale des composants OSGi a deployer dans le conte- 
neur afin de pouvoir utiliser les fonctionnalites de base de Spring Dynamic Modules. Nous 
verrons avec l'etude de cas Tudu Lists que cette liste peut s'enrichir lors de la mise en oeuvre 
de traitements plus complexes. Dans ce tableau, les composants sont regroupes par applica- 
tion ou domaine pour plus de lisibilite. 



Tableau 16-9. Composants de base de Spring Dynamic Modules 



Application 


Description 


Traces applicatives (slf4j, commons-logging 


com.springsource.sl f 4j . api (1 .5.0) 


et log4j) 


com.springsource.slf4j . log4j (1-5.0) 
com.springsource.sl f 4 j .org. apache. commons .logging (1.5.0) 
org.springf ramework.osgi .1 og4j .osgi (1.2. 15. SNAPSHOT) 


Framework Spring 2.5.5 


org. springframework. bundle. spring. beans (2.5.5) 
org.springf ramework. bundle. spring. context (2.5.5) 
org.springf ramework. bundle. spring. aop (2.5.5) 


Framework Spring Dynamic Modules 


org. springframework. bundle. osgi .core (1.1.1) 

org. springframework. bundle. osgi .io (1.1.1) 

org. springframework. bundle. osgi .extender (1.1.1) 


Dependances 


com. springsource.net .sf. cgl ib-2. 1 .3 

com. s pringsource.org. aopal 1 i ance-1 .0.0 
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Remarquons le choix de l'outil SLF4J pour gerer les traces applicatives. L'environnement 
OSGi offre un cadre restrictif, notamment pour le chargement dynamique des classes. Dans 
un tel contexte, l'outil Commons Logging d' Apache revele des faiblesses, et il est recom- 
mande d'utiliser SLF4J. Beaucoup plus robuste, ce dernier possede la caracteristique d'offrir 
differentes distributions en fonction des outils de traces applicatives complementaires utilises. 

Composants compatibles 

Spring Dynamic Modules donne la possibilite de charger et gerer un contexte applicatif 
Spring dans un composant OSGi. Cette gestion est realisee par une entite dediee, qui met en 
ceuvre le patron de conception extender correspondant au composant spring-osgi -extender. 
Nous avons detaille ce patron a la section « Concepts avances ». 

Le patron extender a la responsabilite de charger et decharger les contextes applicatifs Spring 
dans les composants compatibles, a l'instar de l'entite ContextLoaderListener pour les appli- 
cations Web, en se fondant sur les ressources presentes dans les composants. 

Le composant extender utilise l'un des criteres suivants afin de deduire si un composant est 
compatible avec l'outil Spring Dynamic Modules : 

• presence d'un repertoire META-INF/spring contenant des fichiers XML Spring ; 

• presence d'un en-tete Spring-Context dans le fichier MANIFEST.MF, en-tete permettant 
de specifier les fichiers XML a utiliser afin de creer un contexte applicatif Spring. 

Avec le second critere, la valeur specifiee pour 1' en-tete doit correspondre a une liste de 
fichiers, comme dans le code suivant : 

Spring -Context: conf ig/appl i cati onContext-dao.xml , 
conf ig/appl icationCon text -services .xml 

Lorsque la valeur * est specifiee, c'est la premiere strategie qui est utilisee. Cette valeur est 
particulierement utile, car 1' en-tete permet 1' utilisation des directives specifiques recapitulees 
au tableau 16-10 afin de configurer le comportement du composant extender. 



Tableau 16-10. Directives utilisables avec I'en-tete Spring-Context 



Directive 


Description 


create-asynchronously 


Specifie si le contexte applicatif doit etre cree de maniere asynchrone ou synchrone , 
avec respectivement les valeurs true (par defaut) et fal se. 


wai t- for -dependencies 


Specifie si le mecanisme de creation du contexte applicatif doit attendre que les 
dependances obligatoires des services soient resolues, avec respectivement les 
valeurs true (par defaut) et fal se. 


timeout 


Specifie le temps maximal d'attente pour la resolution des dependances obligatoi- 
res. La valeur par defaut est 300 secondes. 


publish-context 


Specifie si le contexte applicatif cree doit etre enregistre en tant que service OSGi, 
avec respectivement les valeurs true (par defaut) et fal se. 



Ces directives s'utilisent de la meme maniere que les directives OSGi standards, comme dans 
l'en-tete Import-Package decrit precedemment. 
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Le code suivant illustre la maniere de specifier une creation synchrone de contexte applicatif 
pour un composant : 

Spring-Context: *;create-asynchronously:-false 

Le code suivant decrit quant a lui comment ne pas publier le contexte applicatif cree en tant 
que service : 

Spring -Context: config/appl icationContext-dao.xml ; publ ish- context : -false 



Parametrage du composant extender de Spring Dynamic Modules 

Spring Dynamic Modules offre la possibilite de parameter le composant extender en se fondant sur les 
fragments OSGi afin notamment de surcharger les options par defaut et d'enregistrer des observateurs 
sur des evenements associes a ces traitements. 

Dans ce contexte, il convient de specifier la valeur org. springf ramework. bundle. osgi .extender 
pour I'en-tete Fragment-Host du fichier MANIFEST.MF du composant correspondant au fragment de 
parametrage. 



Dans le cadre du support Web de Spring Dynamic Modules, un autre extender est propose afin 
de deployer dans un serveur applications Web des applications Web packagees sous forme de 
composants OSGi. 

Dans ce cas, l'un des criteres suivants est utilise : 

• presence de F extension war pour le composant ; 

• presence d'un repertoire WEB-INF a la racine du composant et eventuellement d'un en- 
tete Web-ContextPath dans le fichier MANIFEST.MF. Ce dernier permet de specifier le 
nom du contexte a utiliser lors du deploiement dans le conteneur Web. 

Nous abordons plus en detail la structure d'un composant OSGi contenant une application 
Web a la section relative a la mise en ceuvre de l'etude de cas dans un environnement de ce 
type. 



Parametrage du composant extender Web de Spring Dynamic Modules 

A I'instar du composant extender classique, celui dedie aux composants contenant des applications Web 
peut etre parametre par I'intermediaire de fragments OSGi. Cette mise en ceuvre permet de surcharger la 
strategie de determination du nom du contexte de I'application ainsi que I'entite de deploiement par defaut. 
Dans ce contexte, il convient de specifier la valeur org. springframework. bundle. osgi .web. extender 
pour I'en-tete Fragment-Host du fichier MANIFEST.MF du composant correspondant au fragment de 
parametrage. 



Espace de nommage OSGi 

Comme explique en introduction, l'un des principaux objectifs de Spring Dynamic Modules 
est de permettre l'injection de dependances conjointement et de maniere transparente avec les 
mecanismes de la technologie OSGi. 
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A cet effet, l'outil met a disposition un espace de nommage Spring 2, dont la structure est 
decrite dans le schema XML spring-osgi .xsd, afin de faciliter l'exportation et le reference - 
ment de services OSGi dans un fichier de configuration de Spring. 

Cet espace de nommage se configure d'une maniere classique a l'aide de schemas XML au 
niveau de la balise beans (©), comme dans le code suivant : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. springfrarnework.org/schema/beans" 
xml ns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns :osgi="http: //www. spri ngframework.org/schema/osgi "<— Q 
xsi : schema Location-" http://www.spri ngframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans .xsd 

http: //www. spri ngf ramework.o rg/schema/osgi<— Q 
http: //www. spri ngframework.org/schema/osgi/spring-osgi .xsd"> 

(...) 

</beans> 

Nous allons detailler la maniere d'utiliser cet espace de nommage dans les fichiers de configu- 
ration de Spring. II est a noter que cet espace est uniquement utilisable dans un environnement 
d'execution OSGi puisqu'il se fonde implicitement sur le contexte relatif, a savoir l'interface 
Bundl eContext. 

Referencement de composants 

Une premiere fonctionnalite supportee par l'espace de nommage permet de referencer des 
composants presents dans le conteneur ou de les ajouter s'ils ne sont pas presents. 

La balise bundle, qui en a la charge, correspond a un element de type Bundle, interface de la 
specification OSGi. Elle propose l'attribut symbolic-name afin de specifier Fidentifiant du 
composant relatif, comme dans le code suivant : 

<osgi :bundle id="composantSpringCore" 

symbol i c- name-" org. spri ngf ramework. bundle. spring. core" /> 

Dans le cas oil le composant n'est pas present dans le conteneur, les attributs 1 ocati on, acti on 
et destroy-action peuvent etre utilises en complement afin de specifier respectivement 
F emplacement du fichier du composant a installer et les etats dans lesquels ce composant doit 
se trouver apres l'initialisation et la finalisation du Bean correspondant. 

Lexemple de code suivant permet d' installer le composant contenu dans le fichier tudu- 
web.jar puis de le passer dans l'etat actif (lors de la finalisation du Bean, le composant est 
arrete pour revenir en etat resolu) : 

<osgi :bundle id="composantTuduweb" 
symbol i c-name="tudu.web" 

1 ocati on=" http: //depot /compos ants /tudu- web. jar" 

action="start" 

des t roy - act ion=" stop" 

/> 
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Exportation de services 

Spring Dynamic Modules donne la possibilite d'exporter par declaration tout POJO configure 
dans le contexte de Spring en tant que service OSGi. Pour ce faire, la balise service de 
l'espace de nommage osgi doit etre utilisee. 

La balise servi ce comporte les attributs recapitules au tableau 16-11. 



Tableau 16-11. Attributs de la balise service 



Attribut 


Description 


interface 


Specifie le nom d'interface a utiliser en tant que nom de service. En cas d'utilisation de 
plusieurs noms d'interfaces, la sous-balise interfaces doit etre utilisee. 


ref 


Reference I'instance du Bean a utiliser lors de I'exportation du service. 


depends-on 


Permet de referencer une dependance vers un Bean devant etre initialise avant I'expor- 
tation du service. 


context- class -loader 


Permet de positionner le chargeur de classes du composant courant en tant que char- 
geur de classes pour le thread. Les valeurs possibles sont unmanaged (par defaut), si 
aucun support n'est active, et service-provider, si Spring Dynamic Modules prend 
en charge la gestion du chargeur de classes pour ce thread. 


auto-export 


Specifie la strategie a utiliser afin de deduire automatiquement les noms des interfaces 
a utiliser. Les valeurs possibles sont disabled (par defaut), si aucune strategie n'est 
activee, interfaces, pour utiliser la listedes interfaces implementees, cl ass -hierar- 
chy, pour utiliser la hierarchie des classes meres, et al 1 - cl asses, correspondent a une 
combinaison des deux dernieres valeurs. 


ranking 


Specifie le rang du service. Lors de resultats multiples dans la recherche d'un service, 
le service avec le rang le plus eleve est retourne. La valeur par defaut est 0. 



Les deux attributs les plus courants sont ref (Q) et interface (Q), attributs permettant 
respectivement de referencer le Bean a exposer en tant que service OSGi et de specifier le nom 
de classe utilise en tant qu'identifiant. 

Le code suivant decrit la maniere d'utiliser les deux attributs precedents afin d'exporter le 
Bean todoListsManager (©) : 

<osgi :service ref="todoListsManager"<— Q 

i nterf ace-" tudu. servi ce.Todo Li stsManager" /><— Q 

<bean id="todoListsManager"<— Q 

cl as s-" tudu. servi ce. impl .TodoLi stsManagerlmpl " 

1 azy-init="fal se"> 
(...) 
</bean> 

L'utilisation de la sous-balise interfaces (Q) est envisageable en cas de specification de 
plusieurs interfaces, comme dans le code suivant : 

<osgi :service ref="todoListsManager"> 
<osgi :interfaces><— Q 

<val ue>tudu. service .TodoLi stsManager</val ue> 
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(...) 

</osgi :interfaces> 
</osgi :service> 

(...) 

L'attribut context -cl ass -loader est particulierement interessant en ce qu'il permet de contro- 
ler les entites visibles par le chargeur de classes pour le thread courant. Si la valeur service- 
provi der est specifiee pour l'attribut (Q), Spring Dynamic Modules positionne le chargeur de 
classes du composant courant en tant que chargeur de classes pour le thread avant l'appel du 
service tout en memorisant Fancien. Une fois, l'appel realise, l'ancien est repositionne. Ce 
mecanisme permet de rendre visible les classes de ce composant lors de l'appel de traitements 
d'autres composants. 

Le code suivant illustre la configuration de cet aspect : 

<osgi rservice ref="todol_i stsManager" 

interf ace-" tudu. servi ce.TodoLi stsManager" 
context -cl ass-1 oader=" service -provider" /><— Q 

(...) 



Utilisation du chargeur de classes pour le thread 

Ce chargeur de classes est couramment utilise par differents frameworks et bibliotheques Java EE afin de 
charger des classes. C'est le cas notamment des frameworks Spring et Hibernate. 
Avec ce dernier, le chargeur de classes du composant courant doit necessairement etre positionne pour le 
thread, car le composant Hibernate ne peut pas connaitre a I'avance les classes gerees. Cet aspect 
permet a I'outil d'aller chercher ces dernieres dans le composant qui I'utilise, ces classes etant invisibles 
dans le cas contraire. 

Par exemple, dans le contexte de I'etude de cas Tudu Lists, le composant relatif a I'acces aux donnees 
utilise des classes presentes dans le composant Hibernate. Avec cette approche, le composant Hibernate 
peut charger des classes du composant de Tudu Lists. 



Chaque service exporte avec Spring Dynamic Modules possede la propriete 
org. springframework.osgi .bean. name, dont la valeur correspond au nom du Bean exporte. 
L'outil offre la possibilite de specifier des proprietes additionnelles pour le service en se 
fondant surl'element XML service-properties. 

Cet element comprend un ensemble de cles/valeurs (Q) afin de les definir ainsi que F illustre 
le code suivant avec la propriete maPropriete : 

<osgi rservice id="todoListsManagerService" 
ref="todoLi stsManager" 

interface="tudu.servi ce.TodoLi stsManager "> 
<osgi :service-properties> 

<entry key="maPropriete" value="ma valeur"/><— Q 
</osgi :service-properties> 
| </osgi :service> 
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Spring Dynamic Modules permet de specifier des observateurs pour les evenements d'enre- 
gistrement et de desenregistrement de services grace alabalise registration-listener. Cette 
derniere permet de referencer un Bean d' observation (Q) tout en specifiant les methodes utili- 
sees a cet effet (Q), comme dans le code suivant : 

<osgi :service id="todoListsManagerService" 
ref="todoLi stsManager" 

interf a ce="tudu. service .Todo Li stsManager "> 
<osgi : regi strati on -1 istener ref="monObservateur"><— Q 
<regi stration-method="maPropriete"<— Q 
<un regi strati on -met hod="maPropriete"<— © 
</osgi : registration-1 istener> 
</osgi :service> 

<bean id="monObservateur" cl ass-"tudu.service.MonObservateur"/> 
(...) 

Dans le code ci-dessus, la classe MonObservateur est un Bean simple, sans aucune adherence 
avec une quelconque API OSGi. 

Pour finir, Spring Dynamic Modules definit un nouveau type de portee, nominee bundle, qui 
peut etre utilisee de maniere classique sur n'importe quel element bean par Fintermediaire de 
l'attribut scope. 

Ce dernier ne doit etre utilise que pour un Bean expose en tant que service OSGi. Dans ce cas, 
une instance du Bean est creee par composant utilisant le service par Fintermediaire des API 
OSGi. Une fois qu'un composant correspondant est arrete, Finstance correspondante du Bean 
est liberee. 

Le code suivant decrit la mise en ceuvre de ce mecanisme a l'aide de l'attribut scope (Q) dans 
un fichier de configuration de Spring : 

<osgi :service id="todoListsManagerService" 
ref=" todo Li stsManager" 

interf a ce="tudu. service .Todo Li stsManager "> 

<bean id="todoListsManager" 

cl as s-"tudu. service. impl .Todo Li stsManagerlmpl " 

scope="bundl e"><— Q 
(...) 
</bean> 

Referencement de services 

Une autre fonctionnalite importante de l'espace de nommage reside dans la possibilite de 
referencer, via la balise reference, un service OSGi afin de Futiliser dans la configuration de 
Beans avec l'injection de dependances. L'element relatif au service correspond a un Bean 
classique et peut done etre utilise dans la configuration de l'injection de dependances. 
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Comme plusieurs services OSGi peuvent etre enregistres sous le meme nom, Spring Dynamic 
Modules suppoite aussi bien un referencement simple que multiple, ce dernier par Finterme- 
diaire d'une collection. 

Le referencement simple d'un service OSGi se realise par le biais de la balise reference, dont 
les attributs sont recapitules au tableau 16-12. 

Tableau 16-12. Attributs de la balise reference 



Attribut Description 



interface 


Specifie le nom d'interface que le service doit implemented En cas d'utilisation de plu- 
sieurs noms d'interfaces, la sous-balise interfaces doit etre utilisee. 


filter 


Permet de specifier une expression de filtrage OSGi afin de recuperer le service corres- 
pondent a la restriction specifiee. 


bean-name 


Raccourci permettant de realiser un filtrage sur la propriete org.springfra- 
mework.osgi .bean. name pour les services implementant le ou les interfaces specifiers. 


con text -cl ass-loader 


Offre la possibilite de controler le chargeur de classes pour le thread cour ant. Les valeurs 
possibles sont client et service-provider, pour lesquelles le chargeur de classes 
specifie correspond respectivement a celui du composant appelant du service et a celui 
du composant ayant enregistre le service. La valeur unmanaged (par defaut) est utilisee 
dans le cas ou ce chargeur n'est pas gere par nos soins. 


cardinal ity 


Permet de specifier si le service reference doit etre disponible ou non a tout moment. La 
valeur 1 . . 1 (par defaut) specifie qu'il doit I'etre, et la valeur 0 . . 1 que ce n'est pas le cas. 


timeout 


Specifie le temps d'attente pour qu'un service soit disponible lors de son invocation. S'il 
n'est pas specifie, la valeur de I'attribut default- timeout est utilisee. 



Abordons maintenant les principaux attributs de la balise reference permettant de referencer 
un service OSGi. 

L' attribut 1 nterf ace permet de specifier le nom de l'interface que doit implementer le service. 
Cet attribut s'utilise de la maniere suivante : 

<osgi : reference 

i nterf ace="tudu. service. Todo Li stsManager" /> 

En complement, la sous-balise interfaces (Q) permet de specifier les interfaces devant etre 
implementees : 

<osgi : reference> 

<osgi :interfaces><— Q 

<val ue>tudu.servi ce. Todo Li stsManager</val ue> 
(...) 
</osgi :terfaces> 
</osgi :service> 

L' attribut context -cl ass -loader offre la possibilite de specifier un chargeur de classes en tant 
que chargeur pour le thread courant. Les frameworks et bibliotheques Java EE l'utilisent 
couramment pour charger des classes dynamiquement et rendre visible des classes sans pour 
autant ajouter leurs packages dans le fichier MANIFEST.MF. 
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Chargeur de classes du thread courant 

Le thread courant est celui qui met en oeuvre les traitements dans lesquels se trouve une instruction. La 
technologie Java permet de lui associer differents elements. Dans un environnement Java EE Web, ce til 
correspond au thread de la requete. 

II est possible de lui associer des valeurs specifiques, par I'intermediaire de la classe ThreadLocal , et 
un chargeur de classes specifique, par I'intermediaire de la methode setContextClassLoader de la 
classe Thread. 



La valeur client specifie le chargeur de classes de Fappelant en tant que chargeur pour le 
thread courant. Les classes du composant correspondant sont des lors visibles des autres 
composants dans le cadre d'appels de services. La valeur service-provider permet de posi- 
tionner le chargeur du composant ayant exporte le service. Les classes de ce dernier sont en ce 
cas visibles dans la suite des traitements. 

Le code suivant illustre la mise en oeuvre de l'attribut context-class-loader (0) avec la 
valeur client : 

<osgi : reference interface="tudu.service.TodoListsManager" 
context -cl ass-1 oader="cl ient" /><— Q 

L'attribut cardinality offre la possibilite de specifier si le service doit etre present lors du 
demarrage du contexte applicatif. Avec la valeur 1 . . 1, la reference doit necessairement etre 
resolue a ce moment ; dans le cas contraire, la construction du contexte est suspendue tant que 
cette condition n'est pas resolue. Ce comportement par defaut est modifiable en specifiant la 
valeur 1 . . 0 (Q), comme dans le code suivant : 

<osgi : reference interface="tudu. service. TodoLi stsManager" 
cardinal ity="l. .0" /><^Q 

Pour permettre a des applications de referencer simultanement une liste des services corres- 
pondant a un meme nom, les balises set et list peuvent etre utilisees. La premiere balise 
correspond a la notion d' ensemble et la seconde a une liste, comme defini dans le framework 
de collections de Java. La premiere n'autorise pas les doublons tandis que la seconde permet 
la presence d' elements identiques. Ces deux balises correspondent respectivement aux types 
java.util .Set et java.util .List. 

Similaires a ceux de la balise reference, les attributs de ces balises sont recapitules au 
tableau 16-13. 



Tableau 16-13. Attributs des balises set et list 



Attribut 


Description 


interface 


Meme semantique que pour la balise reference precedente. 


filter 


Meme semantique que pour la balise reference precedente. 


bean-name 


Meme semantique que pour la balise reference precedente. 


con text -cl ass-loader 


Meme semantique que pour la balise reference precedente. 
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Tableau 16-13. Attributs des balises set et list (suite) 



Attribut 


Description 


cardinal ity 


S'apparente a I'attribut cardinality de la balise reference, mais prend les 
valeurs 1 . . n (par defaut) et 0 . . n. Ces valeurs signifient qu'au moins un service 
doit etre present dans le premier ou que ce n'est pas necessaire dans le 
second. 


comparator-ref 


Specifie le comparateur a utiliser afin de trier I'ensemble ou la liste. 


greedy-proxying 


Permet de rendre visible et utilisable toutes les classes correspondant au ser- 
vice en dehors des interfaces declarees. Les valeurs possibles sont true et 
f al se (par defaut), respectivement pour activer et desactiver ce mecanisme. 



La mise en ceuvre de I'attribut interface se realise de la meme maniere que pour la balise 
reference, comme le montre le code suivant : 

<osgi:set i nterf ace="tudu . service. TodoListsManager" /> 

Les differences principales entre ces balises resident dans 1' utilisation des attributs 
comparator-ref et greedy-proxying. 

Le premier donne la possibilite de specifier une instance de l'interface Java Java . utll . Compa - 
rator afin de trier automatiquement les collections correspondantes. Cette instance doit etre 
configuree dans Spring (Q) et est referencee (Q) de la maniere suivante : 

<osgi :set i nterf ace="tudu . servi ce .TodoLi stsManager" 
compa ra tor -ref="serviceCompa rator" /><— Q 

<bean id="servi ceComparator"<— Q 

class="tudu.util .CustomServiceComparator" /> 

Lattribut greedy-proxying permet de creer un proxy pour le service afin d'utiliser toutes les 
classes correspondant au service en dehors des interfaces declarees. Ces classes doivent toute- 
fois etre visibles du composant au sens d'OSGi. Sa configuration s'effectue de la maniere 
suivante : 

<osgi :set i nterf ace="tudu . servi ce .TodoLi stsManager" 
greedy-proxying-"true" /> 

Cela rend possible le transtypage des instances du service (Q), comme dans le code suivant : 

String todoListld = (...) 

for (Iterator i = services. iteratorO ; 1 .hasNextO ;) { 
TodoListsManager service 

= (TodoListsManager) i.nextO; 
service. findTodoList(todoListld) ; 

if (service instanceof MessageDispatcher) {<— O 
((MessageDispatcher)service) .notify( ) ; 

} 

} 
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Spring Dynamic Modules possede un support permettant de gerer les elements dynami- 
ques de la technologie OSGi, notamment pour les collections de services. Les references 
relatives a ces derniers sont ajoutees et supprimees en fonction de leur presence dans le 
conteneur. 



En resume 

Spring Dynamic Modules propose un cadre interessant pour faciliter la mise en ceuvre de 
contextes applicatifs Spring au sein des composants OSGi en se fondant sur des patrons de 
conception tels que extender. 

Ce patron, qui est au cceur du fonctionnement de l'outil, a la responsabilite de parcourir les 
composants possedant des fichiers de configuration de Spring. Si tel est le cas, il cree un 
contexte applicatif Spring pour le composant de maniere transparente en se fondant sur ses 
informations. Une version Web de cette entite permet de configurer et d'enregistrer auto- 
matiquement aupres d'un conteneur Web des composants contenant une application Web 
Java EE. 

En parallele, Spring Dynamic Modules fournit un espace de nommage osgi facilitant la 
configuration des elements relatifs a OSGi et permettant la configuration de traitements de 
ce type par declaration. Grace a cet espace, il est notamment possible d'enregistrer des 
POJO en tant que services OSGi et de les referencer afin de les faire participer a 1' injection 
de dependances. 

Spring Dynamic Modules implemente les bonnes pratiques d'utilisation d'OSGi afin d'adres- 
ser certains problemes classiques relatifs aux chargeurs de classes. Parmi ces bonnes pratiques 
citons au premier chef le positionnement a bon escient du chargeur courant pour le thread lors 
de Fappel d'un service OSGi, qui se revele particulierement interessant lors de F utilisation 
d'outils tels qu'Hibernate. 



Mise en oeuvre de Spring Dynamic Modules dansTudu Lists 

Dans le cadre de l'etude de cas, une version allegee de l'application Tudu Lists est realisee 
avec une structuration en trois modules distincts, structuration en adequation avec les 
differents mecanismes et couches applicatives. Ces dernieres correspondent globalement a 
des traitements permettant d'acceder aux donnees et de les afficher dans une interface 
Web. Les technologies Spring MVC et Hibernate ont ete choisies pour cette version de 
l'application. 

Nous avons choisi les trois composants OSGi suivants afin de mettre en ceuvre l'application 
Tudu Lists dans cette technologie : 

• Composant mettant a disposition un service relatif a la source de donnees afin d'acceder a 
la base de donnees utilisee. 

• Composant d'acces aux donnees permettant de gerer l'interaction et l'utilisation de la base 
de donnees en se fondant sur le service de source de donnees precedent. 
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• Composant de presentation des donnees ail travers d'une interface graphique Web. L'inte- 
raction avec la base de donnees se realise par Fintermediaire des services mis a disposition 
par le composant precedent. 

En complement, deux fragments doivent etre realises arm de configurer les traces applicatives 
et de specifier au pool de connexions le pilote JDBC utilise. 

La figure 16-7 illustre ces differents composants ainsi que leurs relations reciproques. 
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Figure 16-7 

Relations entre les composants OSGi de 1' application Todo Lists 



Composants relatifs aux bibliotheques utilisees 

Lors de la mise en ceuvre d'une application sous forme de composants, le rassemblement des 
composants tiers utilises se revele une operation delicate puisque ces composants doivent etre 
relies de maniere adequate les uns avec les autres et que toutes leurs dependances doivent etre 
resolues. 

Avant de commencer le developpement, il faut identifier les composants OSGi a utiliser ainsi 
que leurs dependances. Cette recuperation peut etre automatisee par Fintermediaire d'outils 
tels que Maven. 

Pour notre application, trois groupes de composants peuvent etre distingues : 

• composants et dependances relatifs a Spring et Spring Dynamic Modules (voir le 
tableau 16-14) ; 

• composants relatifs a Hibernate (voir le tableau 16-15) ; 
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Tableau 16-14. Composants relatifs a Spring et Spring Dynamic Modules 



Application 

Spring 2.5.5 



Spring Dynamic Modules 1.1.1 



Traces applicatives 



Dependances 



Dependance 



Composants 

org. springframework. bundle. spring. co re (2.5.5) 
org. springframework. bundle. spring. beans (2.5.5) 
org. springframework. bundle. spring. context (2.5.5) 
org. springframework. bundle. spring. context. support (2.5.5) 
org.springframework.bundle.spring.aop (2.5.5) 
org.springf ramewor k. bundle. spring, jdbc (2.5.5) 
org.springframework.bundle.spring.orm (2.5.5) 
org.springframework.bundle.spring.tx (2.5.5) 
org.springf ramewor k. bundle, spring, web (2.5.5) 
org.springf ramewor k. bundle, spring, webmvc (2.5.5) 
org. springframework. bundle. osgi .core (1.1.1) 
org. springframework. bundle. osgi .io (1.1.1) 

org. springframework. bundle. osgi .extensions. annotations (1.1.1) 

org. springframework. bundle. osgi .extender (1.1.1) 

org. springframework. bundle. osgi .web (1.1.1) 

org. springframework. bundle. osgi .web. extender (1.1.1) 

com. springsource.sl f4j . api (1.5.0) 

com. springsource. slf4j .log4j (1.5.0) 

com. springsource.sl f 4j .org. apache. commons . 1 ogging (1.5.0) 
org. springframework. osgi .log4j .osgi (1.2. 15. SNAPSHOT) 
com. s pringsource.org. aopal 1 i a nee (1 .0.0) 
com. springsource.net .sf. egl ib (2.1.3) 



Tableau 16-15. Composants relatifs a Hibernate 
Description 



Hibernate 3.2.6 GA 


com 


springsource 


org. hibernate (3.2.6.ga) 


Dependances 


com 


springsource 


antlr (2.7.7) 




com 


springsource 


org. apache. commons. beanuti Is (1.7.0) 




com 


springsource 


javax.xml .stream (1.0.1) 




com 


springsource 


org. apache. commons . col 1 ections (3.2.0) 




com 


springsource 


javassist (3.3.0.ga) 




com 


springsource 


org.dom4j (1.6.1) 




com 


springsource 


org.objectweb.asm (1.5.3) 




com 


springsource 


org.objectweb.asm.tree.attrs (1.5.3) 




jta (1.0.1) 




Pilote JDBC 


com 


springsource 


org.hsqldb (1.8.0.9) 



composants relatifs a Tomcat et aux outils Web utilises (voir le tableau 16-16). 
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Tableau 16-16. Composants relatifs a Tomcat et aux outils Web 



Dependance 


Description 


Tomcat 5.5.23 


o r g. springframework. os gi .catalina.osgi (5. 5.23. SNAPSHOT) 
org. springframework. osgi . jasper. osgi (5. 5. 23. SNAPSHOT) 
org. springf ramework.osgi . catal ina .start .osgi (1 .0.0.SNAPSHOT) 
com. springsource.org. apache. commons . di gester (1 .8.0) 


Servlets et JSP 


com.springsource. j a vax.se rvlet.jsp (2.1.0) 
com. springsou r ce.javax.se rvl et (2.5.0) 


JSTL 


com.springsource. j a vax.se rvlet.jsp. jstl (1.1.2) 

com.springsource. javax.el (2.1.0) 

com. springsource.org. apache, t a gl ibs . standard (1 .1.2) 

org. springframework. osgi .commons-el .osgi (1 .0.0.SNAPSHOT) 



Notons que le composant relatif a Tomcat doit etre demarre avant le composant correspondant 
a l'extender Web de Spring Dynamic Modules. En effet, ce dernier se fonde sur le service de 
Tomcat afin d'enregistrer les applications Web contenues dans des composants. 

Parametrage des composants existants 

Pour mettre en ceuvre Tudu Lists dans un environnement OSGi, il convient de parameter 
certains composants relatifs a des bibliotheques Java afin d' avoir acces aux traces applicatives 
et de permettre l'utilisation du pilote JDBC. 

Ce parametrage peut s'effectuer par le biais des composants OSGi de type fragment suivants : 

• org. springframework. osgi .log4j. osgi, pour specifier un fichier de configuration 
log4j .properties permettant de parameter les traces applicatives produites par Log4j. 

• com.springsource. com. mchange.v2.c3p0, pour ajouter une dependance vers le composant 
contenant le pilote JDBC a utiliser afin qu'il puisse utiliser la classe correspondante. 

Le premier de ces composants OSGi contient uniquement un fichier nomme log4j .properties 
contenant la configuration souhaitee de Log4j. 

Le code suivant montre comment afficher globalement tous les messages d' information, 
d'avertissement, d'erreur et de debogage produits (sauf pour Spring Dynamic Modules) : 

log4j .rootl_ogger=INFO, console 

log4j . appender.console=org. apache. log4j .ConsoleAppender 

1 og4j . appender . consol e. 1 ayout=org. apache. 1 og4j . Pattern Layout 

log4j .appender. console. layout. ConversionPattern=%-4r [%t] %c %x - %m%n 

log4j . category. org. springframework. osgi =DEBUG . console 

Pour appliquer cette configuration a Log4j, il suffit de preciser dans le fichier MANIFEST.MF de 
note composant que ce dernier est un fragment pour le composant de cet outil (Qi) : 

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
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Bundle-Name: Log4J Configuration 
Bundle-SymbolicName: tudu.osgi .log4j.config 
Bundle-Version: 1.0.0 

Fragment-Host: org.springf ramework.osgi . 1 og4j .osgi ; 

bundl e-version="l . 2. 15"<— Q 

Le second composant est encore plus simple puisqu'il ne necessite qu'une configuration dans 
le fichier MANIFEST.MF pour specifier qu'il est un fragment pour le composant de Foutil 
C3P0 (Q) et Fajout d'une entree dans l'en-tete Import-Package (Q) : 

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: C3P0 Configuration 
Bundle-SymbolicName: tudu.osgi .c3p0.config 
Bundle-Version: 1.0.0 

Fragment -Host: com.springsource.com.mchange. v2.c3p0; 

bundl e - vers ion="0. 9. l"<—0 

Import -Package: org.hsqldb;version="l .8.0.9" < — Q 

Composant source de donnees 

Avec la technologie OSGi, une bonne pratique consiste a dedier un composant a la mise a 
disposition d'une fabrique de connexions JDBC par F intermediate d'un service, cette 
derniere se fondant sur l'interface DataSource de la technologie JDBC. 



OSGi et la classe DriverManager 

En raison des mecanismes de chargement de classes utilises par OSGi, I'usage de la classe Driver- 
Manager n'est pas recommande pour mettre en ceuvre la technologie JDBC. Cette classe preconise en 
effet I'utilisation de CI ass .forName pour charger les pilotes JDBC avant leur utilisation et comporte des 
limitations et des faiblesses en termes de manipulation des chargeurs de classes. 
Cette pratique est done deconseillee, et il est preferable d'utiliser des approches fondees sur I'entite 
DataSource, la fabrique de connexions JDBC et la methode 1 oadCl ass des chargeurs de classes. 



Pour mettre en ceuvre cette source de donnees, Foutil C3P0 est utilise dans le composant. 
C3P0 donne la possibilite de configurer un objet de type DataSource en se fondant sur le nom 
de la classe du pilote, Fadresse de la base de donnees et les identifiant et mot de passe d'acces. 
Cette entite correspondant a un pool de connexions, elle peut etre utilisee dans un environnement 
multithreade. 

Comme le montre le code suivant, cette mise en ceuvre s'appuie sur la classe 
ComboPooledDataSource (0) de Foutil et se realise dans le fichier de configuration de Spring 
du composant. La source de donnees est exposee (©) en tant que service dans OSGi afin de 
pouvoir etre utilisee par les autres composants : 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
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xmlns :osgi=" http://www.spri ngframework.org/schema/osgi " 
xsi :schemaLocation=" 

http://www.springframework.org/schema/beans 
http:/ /www. springframework.org/schema/beans/spri ng - beans .xsd 

http: //www. springframework.org/schema/osgi 
http://www.springframework.org/schema/osgi/spring-osgi .xsd"> 

<bean id="propertyConf igurer" 

cl as s="org.springf ramework. beans .factory.config. 

Property PI acehol derConf igurer "><—© 
<property name="location" val ue="jdbc.properties"/> 
</bean> 

<!-- Source de donnees --> 
<bean id-"dataSource" 

cl ass-"com.mchange . v2. c3pO.ComboPool edDa t a Source 
lazy-init-"false"> 
<property name="driverClass" 

val ue="${ jdbc.dri verCl assName} "/> 
<property name=" jdbcUrl " value="${jdbc.url }"/> 
<property name="user" value="${jdbc.username}"/> 
<property name="password" value="${jdbc.password}"/> 
</bean> 



<!-- Enregi strement de la source en tant que service OSGi --> 
<osgi :service ref-"dataSource"><— Q 
<osgi :interfaces> 

<val ue>javax. sql .DataSource</val ue> 
</osgi :interfaces> 
</osgi :service> 
</beans> 



Organisation des fichiers XML de configuration de Spring 

Dans le contexte de Spring Dynamic Modules, une bonne pratique consiste a separer la configuration des 
Beans Spring classiques et de I'utilisation de I'espace de nommage osgi afin de les exporter en tant que 
services OSGi. Le nommage de ces fichiers peut suivre la regie suivante : module-context.xml pour les 
Beans classiques et osgi-context.xml pour I'utilisation de I'espace de nommage osgi . 

Dans I'exemple precedent, la configuration de la source de donnees aurait pu etre externalisee dans un 
fichier dedie. Pour plus de lisibilite, nous I'avons laissee au meme niveau que les autres Beans Spring. 



Dans le code precedent, remarquons I'utilisation de la classe PropertyPlaceHolderConf igurer 
(©) ann d'externaliser les proprietes JDBC dans un fichier de proprietes jdbc.properties. 
Ce dernier doit etre present a la racine du classpath du composant. 
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Le composant relatif a la source de donnees possede les dependances recapitulees au 
tableau 16-17. 

Tableau 16-17. Dependances du composant de la source de donnees 



Dependance 


Description 




Pilote de base de donnees (HSQLDB) 


org.hsqldb (1.8.0.9) 




Pool de connexion 


com.mchange.v2.c3p0 (0.9.1.2) 




Spring 2.5.5 


org.springf ramework. beans. facto ry.config (2.5.5) 
org. spring-framework. context (2.5.5) 





Au vu des elements du tableau 16-16, le contenu du fichier MANIFEST.MF est le suivant : 

Manifest-Version: 1.0 

Bundle-ManifestVersion: 2 

Bundl e-Name: tudu-datasource-osgi 

Bundl e- Symbol i cName : tudu_datasource_osgi 

Bundle-Version: 1.0.0 

Import -Package: org.springf ramework. beans .factory .conf ig; vers ion=" 2.5. 5" , 
o rg. hsql db ; vers ion=" 1.8. 0.9" , 
org.springf ramework. context; version-" 2. 5. 5" , 
com. mchange.v2.c3p0; version-" 0.9. 1.2" 

Composant d'acces aux donnees 

Une fois le composant relatif a la source de donnees mis en ceuvre, le composant d'acces aux 
donnees peut se fonder sur la source de donnees exportee arm d'interagir avec la base de 
donnees. 

Ce composant utilise la bibliotheque Java Hibernate afin de realiser les traitements d' interac- 
tion avec la base de donnees en se fondant sur JDBC. Des packages relatifs a l'outil, ainsi que 
les packages de base de Spring et ceux relatifs au support d'Hibernate dans Spring, sont a 
importer dans le composant. Comme le composant integre des traitements de gestion des tran- 
sactions, les packages relatifs de Spring doivent etre importes. 

Le composant relatif a l'acces aux donnees possede les dependances recapitulees au 
tableau 16-18. 



Tableau 16-18. Dependances du composant de la source de donnees 



Dependance 


Description 




CGLib 2.1.3 


net . sf .cgl 1b. proxy (2.1.3) 




AOP Alliance 1.0 


org. a opal 1 1 ance. a op (1.0.0) 




Commons Logging 


org. apache. commons . 1 ogging (1.1.1) 




AspectJ 1.6.1 


org. aspect j . 1 ang (1.6.1) 
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Tableau 16-18. Dependances du composant de la source de donnees (suite) 
Dependance Description 



Hibernate 3.2.6 GA 


org 


hibernate (3.2.6.ga) 




org 


hibernate. classic (3.2. 6. ga) 




org 


hibernate.hql (3.2. 6. ga) 




org 


hibernate.hql .antl r (3.2.6.ga) 




org 


hihornato hnl act ? fi nal 




org 


hihornato hnl act av a t- 0 R fisl 

ii i uci lid l.c . iiq i . db l . cacl yo.t-.o .yd } 




org 


hi hornatc hnl act troo d 0 fi na 1 




org 


hihornato hnl act ntil l 1 ^ 0 fi nnl 




org 


hihornato hnl rlaccir /^9Rfia\ 




org 


hihornato lHhr 9 R nal 
11 1 U c [ ildLc.JUUL (O . £..0 . y d J 




org 


hihornato nrovi/ IT v K nsl 
[MUciMdlc.pi U Ay \ O.L. . O. y d | 




org 


hihornato r\rov\/ nnin 9 R n Q 1 

iiiucr iidLc.pi u a y . pu j u \ O . cL . o .y d j 




org 


hihornato nrovi/ nnin filih IT9fi/i3i 

iiiucr 1 1 d l c . p [ u Ay . p u j u . l y i u i o.ii . o. y d j 


Framework Spring 2.5.5 


org 


springframework.aop (2.5.5) 




org 


spri ngf ramework. aop. aspect j (2.5.5) 




org 


springframework.aop. aspectj .autoproxy (2.5.5) 




org 


spri ngf ramework. aop. framework (2.5.5) 




org 


spri ngf ramework. beans .factory (2.5.5) 




org 


springframework. context (2.5.5) 




org 


spri ngf ramework. con text .event (2.5.5) 




org 


springframework. core (2.5.5) 




org 


springframework. dao (2.5.5) 




org 


spri ngf ramework. da o. support (2.5.5) 




org 


springframework. jdbc (2.5.5) 




org 


spri ngf ramework . jdbc . core (2.5.5) 




org 


springframework. jdbc. core. support (2.5.5) 




org 


springframework. orm (2.5.5) 




org 


spri ngf ramework. orm. hi be rnate3 (2.5.5) 




org 


spr i ngf r amewo rk. orm. hi be rnate3. support (2.5.5) 




org 


springframework. transaction (2.5.5) 




org 


spri ngf ramework. transaction, annotation (2.5.5) 




org 


springframework.transaction.config (2.5.5) 




org 


spri ngf ramework. trans act ion. intercept or (2.5.5) 




org 


springframework. transaction .support (2.5.5) 



Le composant relatif a Faeces aux donnees contient les traitements relatifs aux elements 
d'acces aux donnees, aux objets metier ainsi qu'aux services metier. 

Le code suivant illustre la configuration de ces differentes entites dans le fichier application- 
Context.xml localise dans le repertoire META-INF/spring du composant : 

<beans xmlns=" http://www.spr ingframework.org/schema/beans" 

xml ns :xsi="http: //www.w3. org/2001 /XMLSchema-i nstance" 
xmlns:aop=" http://www.spr ingframework.org/schema /aop" 
xml ns :tx="http: //www. spri ngframework.org/schema/tx" 
xml ns:osgi=" http://www.spr ingframework.org/schema/osgi " 
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xsi : schema Location-" 

http: //www. spri ngframework.org/schema/beans 
http :/ /www. springframework.org/schema /beans /spring -beans .xsd 

http://www.springframework.org/schema/aop 
http: //www. springframework.org/schema/aop/spring-aop.xsd 

http: //www. spri ngframework.org/schema/tx 
http://www.springframework.org/schema/tx/spring-tx.xsd 

http: //www. springframework.org/schema/osgi 
http :/ /www. springframework.org/schema/osgi /spring -osgi .xsd"> 

<!-- Services --> 

<bean id="todoListsManager" 

cl a ss="tudu. service. impl .TodoLi stsManagerlmpl " 
lazy-init="false"> 
<property name-"todoLi stDAO" ref="todoListDAO"/> 
<property name="todoDAO" ref="todoDAO"/> 
<property name="userManager" ref="userManager"/> 
</bean> 

(...) 

<!-- DAO --> 

<bean id="todoListDAO" 

class="tudu.domain.dao.hibernate.TodoListDAOImpl " 

lazy-init="false"> 
<property name="sessionFactory" ref="sessionFactory"/> 
</bean> 

(...) 

<!-- Hibernate --> 

<bean id-"sessionFactory" 

cl ass="org. spri ngf ramework.orm. hibernate3. 

Local SessionFactoryBean"<— Q 

lazy-init-"false"> 
<property name="mappingResources"> 
<Hst> 

<val ue>/tudu/doma in /model /User . hbm.xml </val ue> 
<val ue>/tudu/doma in /model /Todo. hbm.xml </val ue> 
<val ue>/tudu/doma in /model /TodoLi st. hbm.xml </val ue> 
</list> 
</property> 

<property name=" hibernate Properties'^ 
<props> 

<prop key="hibernate.dialect"> 

org.hibernate.dialect.HSQLDialect</prop> 
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<prop key="hibernate.show_sql ">true</prop> 
<prop key="hibernate.hbm2ddl .auto">update</prop> 
</props> 
</property> 

<property name="dataSource"> 

<osgi : reference interface="javax.sql .DataSource"<— Q 
timeout="5000"/> 

</property> 
</bean> 

<!-- Services OSGi --> 

<osgi :service ref="todoListsManager"<— Q 

context -cl ass-1 oader="servi ce-provider"><— Q 
<osgi :interfaces> 

<val ue>tudu. servi ce.TodoLi stsManager</val ue> 
</osgi :interfaces> 
</osgi : servi ce> 

(...) 

<!-- Transactions --> 

<bean id="hi bernateTransacti onManager" 

cl ass="org. springf ramework.orni. hibernate3. 

Hi bernateTransacti onManager" 1 azy-ini t="fal se"> 
<property name="sessionFactory" ref="sessionFactory"/> 
</bean> 

<tx:advice id="txAdvice" 

transact!' on -manager-" hi bernateTransacti onManager "> 
<tx:attributes> 

<tx:method name="create*"/> 
<tx:method name="update*"/> 
<tx:method name="del ete*"/> 
<tx:method name="*" read-only="true"/> 
</tx:attributes> 
</tx:advice> 

<aop:config> 

<aop:advisor pointcut="execution(* *. .*ManagerImpl .*(..)) " 
advice-ref="txAdvice" /> 

</aop:config> 
</beans> 

Les services metier sont exposes en tant que services OSGi (©) afin de pouvoir etre utilises 
depuis le composant correspondant a Finterface Web. Les packages relatifs aux objets metier 
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ainsi que ceux correspondant aux interfaces des services metier doivent etre en parallele 
specifies dans l'en-tete Export-Package du fichier MANIFEST.MF. 

Les composants d'acces aux donnees mettent en ceuvre la technologie Hibernate, laquelle 
necessite l'utilisation d'une fabrique de session de type SessionFactory. Cette derniere est 
mise en ceuvre dans notre contexte en se fondant sur la classe Local SessionFactoryBean (Q) 
de Spring tout en utilisant le service OSGi javax. sql . DataSource (Q) mis a disposition par le 
composant relatif a la source de donnees. 

Remarquons l'utilisation de l'attribut context-class-loader (Q) au niveau de l'enregistre- 
ment des services metier en tant que services OSGi. Cet attribut permet d'utiliser le chargeur 
de classes associe au thread courant, qui est indispensable pour qu'Hibernate soit en mesure 
d'utiliser les objets metier. 

Au vu de ces elements et du tableau 16-17, le contenu du fichier MANIFEST.MF est le 
suivant : 

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: tudu-core-osgi 
Bundl e- Symbol i cName : tudu_core_osgi 
Bundle-Version: 1.0.0 

Import -Package: o r g. a pa che. commons. logging; vers ion=" 1.1.1", 
org.hibernate.hql ; vers ion-" 3. 2. 6. ga" , 
org. hi be mate, hql .antl r;version-"3.2.6.ga" , 
org.hibernate.hql .ast;version="3.2.6.ga" , 
org.hibernate.hql .ast.exec;version="3.2.6.ga" , 
org.hibernate.hql .ast.tree;version-"3.2.6.ga" , 
org.hibernate.hql .ast.util ;version="3.2.6.ga" , 
org.hibernate.hql .cl assic;version-"3.2.6.ga" , 
org. hsqldb; vers ion-" 1.8. 0.9" , 

org. springframework. beans. factory; version-" 2. 5. 5" , 
org.springframework.core;version="2.5.5" , 
org.springframework.dao;version="2.5.5" , 
org. springframework. dao. support; version-" 2. 5. 5" , 
org. springframework. jdbc;version="2.5.5" , 
org. springframework. jdbc. core; vers ion-" 2. 5. 5" , 
org. springframework. jdbc. core. support; version-" 2. 5. 5" , 
org.springframework.orm;version="2.5.5" , 
org.springframework.orm.hibernate3;version="2.5.5" , 
org. spr i ngf ramework.orm. hi bernate3. support; version-" 2. 5. 5" , 
org. springframework. transact ion. annotation; vers ion-" 2. 5. 5" 
Export-Package: fr.argia.osgi .domain. model , 
tudu. service 

Composant d' interface Web 

Spring Dynamic Modules offre la possibilite de deployer des composants OSGi en tant 
qu' applications Web par 1' intermediate d'un composant extender Web dedie, nomme 
o rg. spr i ngf ramework. bundl e.osgi .web. extender. 
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Le composant utilise pour ses traitements des entites relatives au support Web de Java EE, 
Spring et Hibernate. II se fonde sur les services exportes en tant que services par le composant 
d'acces aux donnees. 

Le composant relatif a l'interface Web possede les dependances recapitulees au tableau 16-19. 



Tableau 16-19. Dependances du composant de la source de donnees 



Dependance 




Framework Spring 2.5.5 


org. spring-framework. beans. factory (2.5.5) 

org.spri ngf ramework. context (2.5.5) 

org. springf ramework. core. io. support; vers ion (2.5.5) 

org.spri ngf ramework. orm. hi be mat e3. support (2.5.5) 

org. springf ramework. web. bind (2.5.5) 

org.spri ngf ramework. web. context (2.5.5) 

org. springf ramework. web. con text, support (2.5.5) 

org.springframework.web.servlet (2.5.5) 

org. springf ramework. web.se rvlet. handler (2.5.5) 

org. sp r i ngf ramework. web. servlet.mvc (2.5.5) 

org. springf ramework. web. servlet. view (2.5.5) 


Spring Dynamic Modules 1.1.1 


org.springframework.osgi .web. context. support (1.1.1) 


Hibernate 3.2.6 GA 


org. hibernate (3.2.6.ga) 


Servlets et JSP 


javax.servlet;version (2.5.0) 
javax.servlet.http;version (2.5.0) 
javax. servlet. jsp (2.0.0) 


Composants relatifs aux JSP 


com. springsource. javax. servlet. jsp. jstl 
com.spri ngsource.org.apache.tagl ibs .standard 


Composant d'acces aux donnees de Tudu 


tudu. domain. model (1.0.0) 
tudu. service (1.0.0) 



Le composant relatif a l'interface Web de F application Tudu Lists met en ceuvre Spring MVC 
et suit la structure classique des composants de ce type dans le cadre de Spring Dynamic 
Modules : 

• Un repertoire META-INF contenant un fichier MANIFEST.MF de configuration du 
composant est present a la racine de ce dernier. 

• Un repertoire WEB-INF possedant la structure definie par Java EE est present a la racine 
du composant. 

• Les classes du composant se trouvent dans le repertoire WEB-INF/classes, la configuration 
de 1' emplacement des classes a utiliser etant realisee par F intermediate de Fen-tete 
Bundl e-Cl ass Path dans le fichier MANIFEST.MF. 

• Un en-tete Web-ContextPath specifie le nom a utiliser pour le contexte de Fapplication Web 
correspondante, le nom tudu dans notre cas. 

De plus, puisque le composant Web est mis en ceuvre dans un environnement OSGi, l'imple- 
mentation de contexte applicatif relative nommee Osgi Bundl eXmlWebApplicationContext doit 
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etre utilisee. Comme le montre le code suivant, qui coiTespond au fichier web.xml, celle-ci 
doit etre configuree au niveau non seulement de Fobservateur Web de Spring 
ContextLoaderLi stener (Q) mais aussi de la servlet de Spring MVC Di spatcherServl et (Q) : 

<web-app id="WebApp_ID" version="2.4" 

xml ns="http: //java . sun .com/xml /ns/j2ee" 

xml ns :xsi="http: //www. w3.org/2001/XMLSchema- instance" 

xsi : schema Locati on="http: //java . sun .com/xml /ns/j2ee 

http: //java . sun .com/xml /ns/j2ee/web-app_2_4.xsd"> 
<di spl ay-name>tudu-web-osgi</displ ay-name> 



<context-param><— Q 

<param-name>contextCl ass</param-name> 
<param-val ue> 

org.springf ramework.osgi .web. context. support. 

Osgi Bundl eXml WebAppl i cationContext 

</param-val ue> 
</context-param> 

<1 i stener> 

<1 i stener-cl ass> 

org.springf ramework. web. context. Context Loader Listener 

</listener-class> 
</l i stener> 



<servl et> 

<servl et-name>tudu</servl et-name> 
<servlet-class> 

org.springf ramework. web. servlet. Di spat cherServlet 
</servl et-cl ass> 

<1 oad-on-startup>2</l oad-on-startup> 
<init-param><— Q 

<param-name>contextCl ass</param-name> 
<param-val ue> 

org.springf ramework.osgi .web. context. support.* 
Osgi Bundl eXml WebAppl i cationContext 

</param-val ue> 
</init-param> 
</servl et> 



<servl et-mappi ng> 

<servl et-name>tudu</servl et-name> 

<url -pattern>*.do</url -pattern> 
</servlet-mapping> 
</web-app> 

Le code suivant illustre la configuration de Spring MVC dans le fichier tudu-servlet.xml 
localise dans le repertoire WEB-INF. Les differents controleurs sont mis en ceuvre de maniere 
traditionnelle. lis utilisent les differents services exportes dans OSGi (Q) P^" l e composant 
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d'acces aux donnees. Le composant Web doit specifier les packages relatifs aux objets metier 
ainsi qu'aux interfaces des services metier dans Fen-tete Import-Package du fichier 
MANIFEST.MF : 

<?xml version="1.0" encoding="UTF-8"?> 

<beans xml ns="http: //www. spri ngframework.org/schema/beans" 

xml ns :xsi="http: //www. w3. org/2001 /XMLSchema-i nstance" 
xml ns:osgi=" http://www.spr ingframework.org/schema/osgi " 
xsi :schemal_ocation=" 

http: //www. springframework.org/schema/beans 
http: //www. spri ngframework.org/schema/beans/spring -beans .xsd 

http: //www. springframework.org/schema/osgi 
http://www.springframework.org/schema/osgi /spri ng-osgi .xsd" > 

<bean id-"urlMapping" 

cl as s-" org. springf ramework. web. servlet. handler. 

Simpl eLIrl Handl erMapping"> 

<property name="mappings"> 
<props> 

<prop key="/todol i st .do">todol i stControl 1 er</prop> 
(...) 
</props> 
</property> 
</bean> 



<!- 



Control eurs 



> 



<bean id="todol i stControl ler" 

cl ass-"tudu.web.Todol i stControl ler" 
lazy-init="false"> 
<property name="todoListsManager"><— Q 
<osgi : reference 

interface="tudu.service.Todol_istsManager" 
timeout="5000"/> 

</property> 

<property name="userManager"><— Q 
<osgi : reference 

interface="tudu.service.UserManager" 
timeout="5000"/> 

</property> 
</bean> 

(...) 

<bean id="viewResolver" 

cl as s=" org. springf ramework. web. servlet. view. * 

Internal ResourceViewResolver"> 
<property name="viewClass" 

va 1 ue=" org. spr ingf ramework. web. servlet.view. Jstl View" /> 
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<property name="pref ix" val ue="/WEB- INF/jsp/"/> 
<property name="suff ix" value=".jsp"/> 
</bean> 

</beans> 

En se fondant sur les elements decrits dans cette section ainsi que sur le tableau 16-17, le 
contenu du fichier MANIFEST.MF du composant est le suivant : 

Manifest-Version: 1.0 

Bundle-ManifestVersion: 2 

Bundle-Name: tudu-web-osgi 

Bundle-SymbolicName: tudu. war 

Bundle-Version: 1.0.0 

Web-ContextPath : tudu 

Bundle -CI assPath: WEB- INF/cl asses 

Import -Package: javax.servlet;version="2.5.0" , 

javax.servlet.http;version-"2.5.0" , 

javax.servlet. jsp;version="2.0.0" , 

org.hibernate;version="3.2.6.ga" , 

org. spr i ngf r amewor k. beans. factory; vers ion=" 2. 5. 5" , 

org.springframework.context;version="2.5.5" , 

org.springframework.core.io.support;version="2.5.5", 

org. spr i ngf r amewor k. orm. hi be rnate3. support; version-" 2. 5. 5" , 

org. spr i ngf r amewor k.osgi .web. con text .support, 

org.springframework.web.bind;version="2.5.5" , 

org. spr i ngf r amewor k. web. context; vers ion=" 2. 5. 5" , 

org. spri ngf r amewor k. web. context. support ;version=" 2. 5. 5", 

org.springframework.web.servlet;version="2.5.5" , 

org.springframework.web.servlet.handler;version="2.5.5", 

org.springframework.web.servlet.mvc;version="2.5.5" , 

org. spr i ngf r amewor k. web. servlet. view; vers ion-" 2. 5. 5" , 

tudu. domain. model , 

tudu. service 

Require-Bundle: com. springsource. javax.servlet. jsp.jstl ,<— © 
com. spr ingsource.org. apache. t a gl ibs. standard 

Les composants relatifs a JSTL doivent etre specifies (Q) en tant que composants dependants 
du fait du grand nombre de packages a importer. 



En resume 

Malgre les mecanismes relativement simples fournis par OSGi, la mise en ceuvre d' applica- 
tions d'entreprise avec cette technologie comporte de nombreux ecueils, notamment au niveau 
de la creation d'un ensemble coherent de composants pour les frameworks et bibliotheques 
Java EE utilises en amont du developpement. Heureusement, des depots mettent desormais a 
disposition des ensembles complets de composants dans ce contexte. 

Le cloisonnement de chargeurs de classes entraine des comportements peu habituels 
des applications Java EE classiques, lesquels peuvent perturber dans un premier temps. 
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Les elements de resolution des erreurs sont notamment accessibles grace aux outils offerts par 
les conteneurs OSGi pour visualiser les informations relatives aux composants. 

Une utilisation du chargeur de classes pour le thread courant peut parfois permettre de rendre 
visible des classes sans avoir a les specifier dans le fichier de configuration du composant. 
C'est le cas notamment lors de l'utilisation de frameworks tels qu'Hibernate. 

Spring Dynamic Modules contribue grandement a rendre plus accessible la mise en ceuvre 
d' applications d'entreprise dans ce contexte en masquant l'utilisation des API OSGi et en 
prenant a sa charge certains traitements relatifs notamment a 1' aspect dynamique de la techno- 
logie. II reste toutefois indispensable de maitriser les concepts de cette technologie. 



Conclusion 

Afin de resoudre les problematiques liees a la maintenabilite et a l'evolutivite des applica- 
tions, la technologie OSGi apporte un reel benefice. Cette derniere offre la possibilite de 
mettre en ceuvre la programmation par composant ainsi que des architectures orientees servi- 
ces afin de structurer les applications en modules. Cette technologie est particulierement 
legere et peut fonctionner au sein d'une meme machine virtuelle Java. 

Utilisee dans les fondations de l'outil de developpement Eclipse pour la gestion de ces gref- 
fons, la technologie OSGi necessite la mise en ceuvre d'un conteneur afin de gerer les 
composants, leurs dependances et leur cycle de vie associes. Differents conteneurs robustes 
de ce type sont disponibles en Open Source, tels Equinox pour Eclipse, Felix pour Apache 
et Knopflerfish. 

OSGi, dont le principal apport est de mettre en ceuvre des composants applicatifs, se caracte- 
rise par son isolation stricte de chargeurs de classes, sa gestion de leurs dependances a 
F execution et la possibilite d'interagir a chaud avec le conteneur. 

Spring Dynamic Modules permet d'utiliser simplement le framework Spring dans un environ- 
nement OSGi afin de beneficier de tous les avantages de ce dernier, que ce soit pour Finjection 
de dependances et la programmation orientee aspect ou la mise en ceuvre des problematiques 
des applications d'entreprise. Cela se traduit par la fourniture d'entites extender permettant de 
charger automatiquement les contextes applicatifs Spring des composants dans differents 
contextes. Un espace de nommage dedie est egalement mis a disposition afin, principalement, 
d'enregistrer et de referencer des services OSGi. 

Afin de favoriser le developpement d' applications d'entreprise avec OSGi, SpringSource 
propose un depot de composants compatibles OSGi relatifs aux principaux frameworks et 
bibliotheques Java EE. Ces composants peuvent etre utilises librement lors de la mise en 
ceuvre d' applications d'entreprise utilisables dans un conteneur OSGi. 

Bien que cette technologie soit tres prometteuse, elle souffre de limitations liees au cloisonne- 
ment des chargeurs de classes, limitations adressees par l'outil dm Server. Ce dernier, que 
nous decrivons en detail au chapitre suivant, fournit une plate-forme packagee combinant les 
outils et technologies Spring, Tomcat et OSGi. Cette plate-forme, qui offre une flexibilite 
d' administration a chaud, est particulierement adaptee et optimisee pour la mise en ceuvre 
d' applications d'entreprise. 
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Nous avons vu au chapitre precedent les avantages de la technologie OSGi pour structurer les 
applications tout en gerant les dependances entre composants de maniere efficace. L'outil 
Spring Dynamic Modules offre un interessant support pour faciliter l'utilisation du framework 
Spring dans un environnement de ce type. 

Neanmoins, differents problemes et difficultes se posent afin d'obtenir des versions des biblio- 
theques et des frameworks Java EE sous forme de composants OSGi et de constituer un depot 
de composants coherents dans le cadre de la mise en ceuvre d' applications d'entreprise. 

La mise en ceuvre des applications d'entreprise dans des composants OSGi fait apparaitre des 
lourdeurs dues au nombre important des importations de packages, importations necessaires 
afin de referencer des bibliotheques et frameworks Java EE. 

L'outil dm Server permet de depasser ces limitations et de faciliter la mise en ceuvre d' applica- 
tions d'entreprise dans un environnement OSGi. Cet outil fournit en outre differentes briques 
permettant d' administer, de deployer et de superviser les applications contenues dans un serveur 
d' applications. De par sa legerete et sa flexibilite ainsi que de son support de la technologie OSGi, 
on peut parler veritablement d'un serveur d' applications de nouvelle generation. 

Ce chapitre aborde les concepts et 1' architecture de dm Server ainsi que les enrichissements de 
la specification OSGi qu'il propose. Nous verrons egalement les possibilites qu'il offre pour 
structurer les applications et les organiser en composants et finirons par ses particularites de 
configuration et de deploiement. 

Concepts generaux 

Developper des applications d'entreprise dans un environnement OSGi n'est pas toujours une 
tache facile. Cela tient a la complexite des mecanismes utilises dans ce type d' application 
ainsi qu'aux dependances induites par les frameworks et bibliotheques Java EE. 
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Convaincu neanmoins que la technologie OSGi constitue une avancee dans 1' amelioration de 
la structuration et de la modularisation des applications d'entreprise, SpringSource propose 
une brique supplementaire arm de rendre plus simples les developpements de ce type dans un 
environnement OSGi. 



SpringSource 

SpringSource, anciennement appelee Interface 21 , est la societe qui soutient le developpement de Spring 
ainsi que les differents projets et outils crees autour du framework. Cette societe emploie les principaux 
acteurs de la communaute Spring. 



Avant d'entrer dans le detail des caracteristiques de dm Server, revenons sur les principaux 
facteurs contribuant a complexifier la mise en ceuvre d' applications d'entreprise dans un envi- 
ronnement OSGi. 



Complexity 

Avant de mettre en ceuvre les preoccupations des applications, il convient de fournir au conte- 
neur OSGi les frameworks et bibliotheques Java EE necessaires sous forme de composants 
OSGi. Un framework Java EE s'appuyant la plupart du temps sur d'autres outils, frameworks 
ou bibliotheques, la coherence de ces divers composants peut vite s'averer problematique et 
induire des erreurs parfois difficiles a resoudre. 

Comme nous l'avons vu au chapitre precedent, OSGi garantit un cloisonnement strict des 
chargeurs de classes. Cela impose de specifier le package contenant les classes a utiliser lors- 
que ces dernieres se trouvent dans des dependances, cette operation se fondant sur Fen-tete 
Import-Package du fichier MANIFEST.MF. Pour des traitements complexes, le nombre de 
packages a specifier peut vite devenir important et impacter les temps de developpement. 
L' ideal serait de pouvoir importer d'un coup tous les packages pour un framework ou une 
bibliotheque donnee. 

Une autre difficulte d' utilisation de la technologie OSGi tient a F absence de la notion d' appli- 
cation, laquelle correspond a un ensemble de composants OSGi. En consequence, aucune 
possibilite n'est offerte afin de fournir une isolation entre les composants dedies a une appli- 
cation. Meme si OSGi met en ceuvre un cloisonnement strict entre composants, tous les 
composants presents dans le conteneur sont potentiellement visibles et utilisables. Aucun 
compartimentage des applications n'est envisageable a ce niveau. 

Cette lacune impose de travailler sur les composants unitairement, meme si ces derniers 
correspondent a une unique application, ce qui peut vite rendre complexe Fadministration 
d'une application. 

Solutions apportees par dm Server 

Afin de faciliter la mise en ceuvre d' applications d'entreprise dans un environnement OSGi, 
SpringSource propose Foutil Open Source dm Server integrant les technologies et outils reca- 
pitules au tableau 17-1. 
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Tableau 17-1. Technologies et outils in teg res par dm Server 



Outil 


Description 


Spring 


Conteneur leger pour I'injection de dependances et la programmation orient.ee aspect offrant 
divers supports afin de faciliter la mise en ceuvre d'applications Java EE. 


Tomcat 


Conteneur Web Open Source de la fondation Apache disponible a I'adresse http://tomcat.apa- 
che.org/. 


OSGI R4 


Specification pour la mise en ceuvre de la programmation orientee composant ainsi que pour des 
architectures orientees services legeres au sein d'une meme machine virtuelle Java. 


Equinox 


Implementation de la specification OSGi de la plate-forme Eclipse. Cette implementation corres- 
pond au socle de l'outii de developpement. Elle propose un mecanisme de points d'extension non 
normalise pour le moment. 


Spring Dynamic Modules 


Outil permettant la mise en ceuvre d'applications fondees sur le framework Spring dans un envi- 
ronnement OSGi. 


Spring Application 
Management Suite 


Brique applicative adressant la supervision de dm Server et des applications deployees en 
son sein. 



L'outii dm Server se positionne en tant que serveur d'applications de nouvelle generation 
offrant une approche legere et flexible permettant d'envisager la mise en ceuvre et la gestion 
d'applications d'entreprise Java EE. A cet effet, l'outii a fait le choix des technologies Spring 
et OSGi tout en integrant un conteneur Web Tomcat. II est a noter que le serveur d'applications ne 
contient pas de conteneur d'EJB3. 

La figure 17-1 illustre 1' architecture des differentes briques enoncees precedemment, ces 
dernieres etant combinees et etendues afin de tirer parti au maximum les unes des autres. 



Figure 17-1 
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Nous pouvons constater que la brique centrale de Foutil correspond a Dynamic Modules 
Kernel. Cette derniere met en ceuvre tous les concepts de la technologie OSGi. Fondee sur 
Equinox tout en Fenrichissant, elle offre un support relatif a la gestion et a l'approvisionnement 
des bibliotheques. 

Une autre caracteristique interessante de dm Server reside dans F adaptation dynamique des 
ressources necessaires aux composants ann de minimiser la consommation memoire globale 
du serveur d' applications. 

En complement, Foutil permet de diagnostiquer rapidement les erreurs aussi bien en develop- 
pement qu'en production. Ces erreurs peuvent etre notamment induites par des problemes au 
niveau des dependances. Cette fonctionnalite se fonde sur Fisolation et la mise a disposition 
de Fexception etant a Forigine de Ferreur. 

Sur cette brique centrale s'appuient differentes briques applicatives permettant d'enrichir le 
conteneur OSGi lui-meme en fonction de profils, ces derniers offrant la possibilite de beneficier 
notamment de services relatifs a F administration et au deploiement. 

Ces differentes briques permettent a dm Server d'offrir les differents avantages suivants : 

• beneficier des fonctionnalites du framework Spring ann de rendre plus simple la mise en 
ceuvre des traitements des applications d'entreprise ; 

• permettre une structuration en composants des differents traitements d'une application en 
se fondant sur OSGi ; 

• permettre la mise a disposition ainsi que la consommation de services afin de rendre 
possible des architectures orientees services au sein d'une meme machine virtuelle Java ; 

• permettre une administration a chaud des differents composants applicatifs ; 

• offrir des fonctionnalites simplifiant la configuration des dependances entre composants 
OSGi; 

• mettre a disposition des facilites afin de detecter Forigine des erreurs relatives aux depen- 
dances entre composants. 

Comme dm Server est fonde sur la technologie OSGi, il beneficie de toute sa flexibilite, 
notamment au niveau de F administration puisque toutes les operations peuvent etre realisees 
a chaud. II est a noter que Foutil rend accessibles ses differents constituants par Finterme- 
diaire de la technologie standardisee de supervision JMX. 

La technologie OSGi induit egalement une gestion des dependances a F execution ainsi 
qu'une isolation stricte des traitements contenus dans les composants par le biais de chargeurs 
de classes dedies. L'outil dm Server enrichit ces fonctionnalites afin de faciliter et de simplifier 
leur utilisation dans le contexte des applications d'entreprise. 

En parallele de l'outil, SpringSource offre un depot contenant un ensemble de composants 
OSGi relatifs aux bibliotheques et frameworks Java EE courants. L'outil donne la possibilite 
de provisionner son depot local de composants et de bibliotheques directement a partir de 
celui de SpringSource. 
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Gestion des dependances 

Comme indique precedemment, Futilisation de l'en-tete Import-Package de la technologie 
OSGi afin de referencer des packages comporte des limitations dans le cadre des applications 
d'entreprise. En effet, un nombre important de packages doit etre couramment specifie, avec 
la possibilite d'erreurs a Fexecution en cas d'oublis. 

Dans ce contexte, dm Server introduit une notion plus globale que les packages afin de refe- 
rencer et d'utiliser des dependances. Cette notion correspond au concept de bibliotheque, ce 
dernier representant un ensemble coherent de composants OSGi lies a une bibliotheque ou un 
framework Java. II est a noter que le concept de bibliotheque est introduit afin de combler son 
manque actuel dans la specification OSGi. Cela apporte une fonctionnalite interessante lors de 
Futilisation de frameworks ou bibliotheques Java, un grand nombre de packages devant etre alors 
importes. 

Ce concept est particulierement interessant pour le developpement puisque Fensemble des 
packages relatifs n'est pas forcement connu a Favance et doit etre complete progressivement 
au cours du developpement. De plus, une omission de packages necessaires a Fexecution se 
traduit couramment par une erreur dont le diagnostic est loin d'etre trivial. 

Utilisation de dependances 

Afin de minimiser le nombre de lignes contenu dans la valeur de Fen-tete Import-Package, 
dm Server dispose de deux nouveaux en-tetes. Ces derniers, Import-Bundle et Import -Library, 
correspondent uniquement a des alias pour un ensemble de packages definis dans OSGi. lis 
possedent done la meme semantique que Fen-tete Import- Package et correspondent simple- 
ment a des alias. lis sont automatiquement convertis en une liste des Import-Package corres- 
pondants, offrant ainsi la possibilite de reduire de maniere significative le nombre de lignes 
relatives a la specification des dependances dans le fichier MANIFEST.MF. 

L'en-tete Import-Bundle permet de referencer d'un coup tous les packages exportes par un 
composant. La valeur de ce dernier suit les memes regies qu'un en-tete OSGi classique, a savoir 
une liste d'elements separes par des virgules, avec la possibilite de specifier des directives. 

Par defaut, la specification d'un composant par ce biais impose sa presence. Cela peut toute- 
fois se modifier par le biais de la directive resol uti on. Cette derniere se comporte de la meme 
maniere que dans Fen-tete Import-Package. L'en-tete Import-Bundle offre egalement la possi- 
bilite d'utiliser la directive versi on afin de specifier la version ou une plage de versions lors du 
referencement de la dependance. 

La figure 17-2 illustre le principe d'une configuration de dependances fondee sur l'en-tete 
Import-Bundl e. 

Le code suivant illustre Futilisation de l'en-tete Import-Bundl e afin de referencer les packages 
exportes par l'outii DBCP : 

Import-Bundle: com. springsource.org. apache. commons. dbcp; 
version="[1.2.2.osgi , 1.2.2.osgi]" 

L'en-tete Import- Library permet de referencer d'un coup tous les packages exportes par un 
ensemble de composants. La valeur de cette derniere suit les memes regies qu'un en-tete 
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OSGi classique, a savoir une liste d' elements separes par des virgules, avec la possibilite de 
specifier des directives. A Finstar de Fen-tete Import-Bundle, les directives resolution et 
version sont utilisables avec les merries mecanismes que precedemment. 



Figure 17-2 
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La figure 17-3 illustre le principe d'une configuration de dependances fondee sur Fen-tete 
Import-Library. 
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Le code suivant illustre l'utilisation de l'en-tete Import-Library afin de referencer les packa- 
ges exportes par les outils Spring et AspectJ : 

Import- Library: org.springf ramework.spring;version-"[2.5.4, 3.0)" , 
org. aspect j ; versi on="[l .6.0,1.6.0]"; resol ution :=" optional " 

Definition d'une bibliotheque 

La fonctionnalite relative aux bibliotheques est extensible puisque dm Server offre la possibi- 
lite de definir ses propres bibliotheques. Cela se configure par le biais d'un fichier possedant 
l'extension 1 i bd et offrant la possibilite de definir les proprietes de la bibliotheque ainsi que 
les composants qui la constituent. 

Le tableau 17-2 recapitule les en-tetes utilisables dans ce type de fichier, ce dernier suivant le 
style de configuration des fichiers MANIFEST.MF. 



Tableau 17-2. En-tetes utilisables dans la definition des proprietes d'une bibliotheque 



En-tete 


Description 


Library -Symbol i cName 


Definit le nom symbolique ou identifiant de la bibliotheque. 


Library-Version 


Specifie la version de la bibliotheque. 


Import-Bundl e 


Definit la liste des composants contenus dans la bibliotheque. La directive version 
peut etre utilisee au niveau de chaque composant specifie. 


Library-Name 


Definit le nom de la bibliotheque. 


Library -Description 


Permet de specifier une description de la bibliotheque. Ce parametre est optionnel. 



L'exemple suivant illustre la mise en ceuvre d'un fichier 1 ibd correspondant a la bibliotheque 
Spring d'identifiant org. springframework. spring en se fondant sur les en-tetes Library- 
Symbol icName (©), Library-Version (©), Library-Name (Q) et Import-Bundle (Q) : 

Library -Symbol icName: org.springf ramework.spring<— © 
Library-Version: 2.5. 4< — Q 
Library-Name: Spring Framework<— Q 

Import -Bundle: o rg. spr i ngf ramework. core; versi on=" [2. 5.4,2.5. 5)" , <— Q 
org.springframework.beans;version="[2.5.4,2.5.5)" , 
org. spr ingf ramework. context; vers ion="[2.5. 4,2. 5. 5)" , 
org.springframework.aop;version="[2.5.4,2.5.5)", 
org.springframework.web;version="[2.5.4,2.5.5)", 
org.springframework.web.servlet;version-"[2.5.4,2.5.5)" , 
org. spr ingf ramework. jdbc; vers ion="[2.5. 4,2. 5.5)" , 
org.springframework.orm;version="[2.5.4.2.5.5)", 
org.springf ramework. transaction ; versi on-" [2. 5. 4,2. 5. 5)" , 
org. spr ingf ramework. context. support; versi on-" [2. 5. 4, 2. 5. 5)" , 
org. spr ingf ramework. aspects ;version="[2.5.4,2.5.5)" , 
com.springsource.org.aopal 1 i ance; versi on-" 1 .0" 
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Ce code utilise la directive version au niveau de chaque element de la balise Import-Bundle 
afin de specifier les versions utilisees. 

Nous verrons a la section « Gestion du depot de bibliotheques » comment configurer des 
bibliotheques dans dm Server. 



En resume 

Apres avoir constate que la mise en ceuvre des applications d'entreprise dans un environ- 
nement OSGi souffrait de quelques lourdeurs, nous avons decrit les concepts proposes par 
dm Server afin de pallier ces limitations. 

L'outil dm Server correspond veritablement a un serveur d' applications de nouvelle genera- 
tion visant a offrir une plate-forme legere, facilement administrate et adaptant les ressources 
utilisees en fonction des besoins. Cette plate-forme integre Tomcat, Spring et OSGi, tech- 
nologies et outils utilises conjointement afin de tirer parti au maximum les unes des autres. 

Cet outil possede done toute la flexibilite et la modularisation induites par OSGi, tout en 
offrant la possibilite d'utiliser les mecanismes de Spring simplifiant l'utilisation des 
frameworks Java EE. 

L'outil dm Server enrichit egalement la technologie OSGi afin d'introduire le concept de 
bibliotheque dans le but de simplifier la gestion des dependances entre composants OSGi. 
Cette derniere permet en effet de specifier en une seule instruction les composants ainsi que 
les packages necessaires a l'utilisation d'une bibliotheque ou d'un framework Java en tant que 
dependance. De nouveaux en-tetes sont mis a disposition afin d'utiliser ce concept directement 
dans le fichier MANIFEST.MF. 



Structuration des applications 

Une fonctionnalite importante de dm Server est le support des applications Web classiques de 
Java EE. Ces applications sont en effet supportees en tant que telles et deployables directe- 
ment dans l'outil. Cela permet d'utiliser au sein meme de l'outil des applications existantes 
fonctionnant, par exemple, dans Tomcat. 

En complement, et puisque dm Server repose sur la technologie OSGi, il supporte les compo- 
sants de ce type tout en offrant des enrichissements pour differents domaines. Ces types 
de composants peuvent etre deployes directement ou par l'intermediaire d'une application les 
contenant. 

Le tableau 17-3 recapitule les differentes unites de deploiement supportees par dm Server. 

Les composants OSGi classiques et la technologie sous-jacente ont ete abordes au chapitre 
precedent. Ces derniers peuvent tirer parti des mecanismes de Spring Dynamic Modules 
afin d'utiliser en leur sein le framework Spring ainsi que toutes les fonctionnalites corres- 
pondantes. 
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Tableau 17-3. Unites de deploiement supportees par dm Server 



Unite 


Description 


WAR (web archive) 


Artefact correspondant aux applications Web Java EE, dont la structure est 
decrite par la specification correspondante. 


Composants OSGi olassiques 


Artefact correspondant aux composants normalises par la specification OSGi et 
utilisables dans un conteneur de ce type. 


Modules Web 


Artefact correspondant a des composants OSGi specialises dans la mise en 
ceuvre d'applications Web. 


PAR 

I 


Artefact correspondant a la mise en ceuvre du concept d'application dans un 
environnement OSGi. 



La section suivante aborde les autres types d' unites de deploiement supportes par dm Server. 

Fichiers WAR 

L'outii dm Server supporte en natif les fichiers WAR (web archive) contenant des applica- 
tions Web et dont la structure est definie dans la specification Servlet de Java EE. L'outii 
propose differentes approches en fonction du degre d' utilisation de la technologie OSGi 
souhaitee. Nous allons passer en revue cette technologie, selon un niveau croissant 
d'utilisation. 

Dans la mise en ceuvre d'archives Web, il est possible d'utiliser Fen-tete Web-ContextPath afin 
de specifier le contexte de F application Web correspondante. Si ce dernier n'est pas utilise, le 
nom du fichier de 1' archive est utilise. Comme cet en-tete peut egalement etre utilise dans les 
modules Web, nous l'aborderons plus en detail a la section correspondante. 

Fichiers WAR classiques 

Le premier type d' archive relative aux applications Web supporte correspond aux archives 
classiques, au sens de la specification Servlet de Java EE. Cela permet d'utiliser au sein de 
dm Server des applications Web developpees pour un serveur d'applications classique, tel que 
Tomcat. 

Dans ce contexte, 1' archive de 1' application Web contient les differents elements suivants : 

• classes et ressources relatives au tiers de presentation permettant de mettre en ceuvre Finter- 
face graphique Web ; 

• fichiers de configuration de 1' application tels que le fichier web.xml ; 

• classes et ressources relatives au tiers metier ou classes permettant d'acceder a ce tiers de 
maniere distante ; 

• fichiers jar correspondant aux bibliotheques et frameworks utilises afin de mettre en ceuvre 
les traitements de F application Web. Ces fichiers sont localises dans le sous-repertoire lib 
du repertoire WEB-INF. 
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Fichiers WAR utilisant des bibliotheques partagees 

Dans le second type d' archive, les bibliotheques et frameworks utilises sont externalises de 
F archive et references en se fondant sur les mecanismes de gestion des dependances de la 
technologie OSGi ainsi que sur les fonctionnalites supplementaires apportees par dm Server. 

Ce type de fichier correspond a un fichier WAR classique integrant le support OSGi afin de 
resoudre les dependances. En consequence, les fichiers jar de ces dernieres ne sont plus 
presents dans F archive. 

Les dependances doivent etre installees dans l'outil en tant que composants OSGi referen- 
ces dans le fichier MANIFEST.MF de 1' application Web en se fondant sur les en-tetes 
OSGi et de dm Server, tels que Import-Package, Import-Bundle et Import-Library (voir 
figure 17-4). 



Figure 17-4 

Structure d'un fichier WAR 
utilisant des bibliotheques 
partagees dans dm Server 



Application Web 



Elements classiques 
(classes , ressources, 
fichiers de 
configuration 



Fichier 
MANIFEST.MF 



Import- (Package 
Import- Bundle 
Import Library 



Dependance (Composant ou 
bibliotheque) 



Export-Package 



Export-Package 



Dependance (Composant ou 
bibliotheque) 



Export-Package 



Export-Package 



Fichiers WAR utilisant des services par tag es 

Ce dernier type d' archives Web permet, en plus de l'utilisation de bibliotheques partagees, 
mecanisme decrit a la section precedente, d' avoir acces et d'utiliser les services OSGi 
presents dans le conteneur en se fondant sur l'espace de nommage osgi de Spring Dynamic 
Modules. 

Cela permet d'externaliser de l'application Web les traitements qui ne sont pas relatifs au tiers 
de presentation, tout en restant dans la meme machine virtuelle Java. Ces traitements sont 
desormais presents dans le conteneur OSGi sous forme de services et sont utilisables depuis 
l'application en se fondant sur les mecanismes standards de la technologie OSGi. Ainsi, seuls 
les traitements specifiques a F interface graphique Web restent desormais presents dans 
l'application. 
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La figure 17-5 illustre les interactions possibles entre une application Web de ce type et ses 
dependances presentes dans le conteneur OSGi. 



Figure 17-5 

Structure d'un fichier WAR 
utilisant des services 
portages dans dm Server 
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Elements classiques 
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fichiers de 
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MANIFEST.MF 
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Import- Package 



Import- 



Import- 



Dependance (Composant ou 
bibliotheque) 



Service OSGi 



Export-Package 



Bundle 
Library 



Dependance (Composant ou 
bibliotheque) 



Export-Package 



Export-Package 



A Finstar des composants Web supportes par Spring Dynamic Modules, les artefacts WAR utili- 
sant des services partages necessitent une configuration specifique afin d'utiliser un contexte 
applicatif de Spring sachant interagir avec un environnement OSGi au sein de dm Server. Ce 
contexte applicatif est propose par le biais de la classe Serve rOsgi -Bundl eXml WebAppl i cation. 

Pour une mise en ceuvre de ce type de contexte dans le contexte applicatif general de F appli- 
cation Web, cette derniere classe doit etre specifiee au niveau de Fobservateur Web de Spring 
dans le fichier web.xml en se fondant sur sa propriete contextCl ass (reperes Q>. comme dans 
le code suivant : 

<context-param> 

<param-name>contextCl ass</param-name><— Q 
<param-val ue> 

com. springsource. server. web. dm. ^* 

Serve rOsgi Bundl eXml WebAppl i cationContext<— Q 
</param-val ue> 
</context-param> 

<listener> 

<listener-class> 

org. springf ramewor k. web. context .Con text Loader Li stener 
</l i stener-cl ass> 
</l i stener> 
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II est recommande de referencer exclusivement les services OSGi au niveau de ce contexte. 
Leur utilisation reste neanmoins possible au niveau du contexte applicatif associe a une 
servlet DispatcherServlet de Spring MVC. 

Cette meme classe doit etre specifiee au niveau de la configuration de la servlet 
DispatcherServlet dans le fichier web.xml par le biais de la propriete contextCl ass (repe- 
res Q). comme dans le code suivant : 

<servl et> 

<servl et-name>springmvc-servl et</servl et-name> 
<servlet-class> 

org.springf ramework. web. servlet. Di spat cherServlet 
</servl et-cl ass> 
<init-param> 

<param-name>contextCl ass</param-name><— Q 
<param-val ue> 

com. springsource. server. web. dm. 

ServerOsgi Bundl eXml WebAppl i cationContext<— Q 
</param-val ue> 
</init-param> 
</servlet> 

Une fois ces aspects configures, il est possible d'utiliser la balise reference de Fespace de 
nommage osgi de Spring Dynamic Modules ainsi que toutes les autres fonctionnalites de 
Fespace au sein de F application Web. 

Le code suivant decrit F usage de cette balise afin de referencer un service exposant un service 
metier par F intermediate de Finterface TodoLi stsManager : 

<osgi :reference id="dataSource" 

interface="tudu.service.TodoListsManager"/> 



Modules Web 

Bien que dm Server supporte directement les composants OSGi, Foutil apporte en comple- 
ment la notion de module, ce dernier correspondant a la specialisation d'un composant OSGi 
pour un domaine specifique. A Fheure actuelle, Foutil ne propose que des composants de 
type Web. 

Tout en integrant les mecanismes des WAR decrits precedemment, les modules Web vont plus 
loin en offrant des fonctionnalites relatives a cette preoccupation. 

• configuration d' elements du fichier web.xml directement dans le fichier MANIFEST.MF 
d'une maniere plus simple ; 

• configuration automatique de la servlet Di spatcherServl et de Spring MVC ; 
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• mecanisme de chargement du contexte applicatif de Spring fonde sur 1' « extender » clas- 
sique de Spring Dynamic Modules. 

Afin de deflnir un composant OSGi en tant que module Web, il suffit d'utiliser l'en-tete 
Module-Type dans le fichier MANIFEST.MF. L'en-tete prend dans ce cas la valeur Web. 
Le code suivant illustre la configuration correspondante (0) au sein de ce fichier : 

Module-Type: Web<— Q 
Bundle-Version: 1.0.0 
Bundle-Name: tudu-web 
(...) 

Puisqu'un module est avant tout un composant OSGi, tous les mecanismes de cette technologie 
sont utilisables pour la gestion des dependances. Les fonctionnalites offertes par dm Server, 
telles que le support des bibliotheques en tant que dependances afin de faciliter l'utilisation 
d'OSGi, le sont egalement. 

Entrons maintenant dans le detail des specificites de ce type de composants de dm Server. 
Fonctionnement 

Dans le contexte de dm Server, un module Web correspond a un composant OSGi classique 
integrant Spring et configure par 1' intermediate de l'entite « extender » simple de Spring 
Dynamic Modules. A la difference de ce dernier outil, ce composant n'a pas besoin d'une 
entite « extender » Web dediee pour sa configuration. 

Pour ce type de composant, la gestion du contexte applicatif est evoluee puisqu'un ensemble 
de traitements sont realises automatiquement et implicitement. Le contexte est automatique- 
ment cree en se fondant sur les mecanismes de l'« extender » de Spring Dynamic Modules. 
En parallele, une servlet DispatcherServlet de Spring MVC est creee et configuree en utili- 
sant le contexte applicatif precedent. Les elements relatifs au MVC doivent done etre configures 
dans ce contexte. 

Les differentes ressources de 1' application Web doivent se trouver dans le repertoire 
MODULE-INF, lequel doit eventuellement etre present directement a la racine du module. 
Ce repertoire correspond a la racine du contexte de 1' application. 

A l'instar du fonctionnement des applications Web classiques, les ressources presentes sous le 
repertoire precedent sont visibles directement depuis l'exterieur de 1' application. De plus, le 
repertoire MODULE-INF peut eventuellement contenir un sous-repertoire WEB-INF. Ce 
repertoire ainsi que toutes les entites qu'il contient sont invisibles depuis l'exterieur de 
1' application. Une bonne pratique consiste a placer les fichiers de configuration ainsi que les 
ressources internes a cet endroit. 

La figure 17-6 illustre la structure d'un module Web, type d'entite mis a disposition par 
dm Server. 
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Figure 17-6 

Structure d'un module Web 
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En-tetes specifiques 

La mise en ceuvre d'un module Web permet l'utilisation d'en-tetes dedies afin de configurer 
des elements relatifs a des elements Web et de Spring MVC. Ces differents en-tetes sont reca- 
pitules au tableau 17-4. 

Tableau 17-4. En-tetes specifiques des modules Web 



En-tete 


Description 


Web-ContextPath 


Permet de specifier le contexte de I'application Web. 


Web-FilterMappings 


Permet de configurer un ou plusieurs filtres servlet par I'intermediaire 
d'une chaine de caracteres separee par des virgules. Les directives 
targetFi 1 terl_i fecycl e, url -patterns et dispatcher permettent 
de specifier respectivement I'activation de la delegation des evene- 
ments au filtre, le mappage ainsi que le type d'application. 


Web-DispatcherServletUrl Patterns 


Permet de specifier le mappage de la servlet DispatcherServlet 
creee implicitement. 



Le premier en-tete permet de preciser le contexte de I'application Web, c'est-a-dire le nom 
virtuel a partir duquel cette derniere peut etre accedee. Le code suivant illustre l'utilisation de 
cet en-tete dans le fichier MANIFEST.MF du module : 

I Module-Type: Web 

| Web-ContextPath: tudu^Q 

Comme indique a la section precedente, une servlet Di spatcherServl et est implicitement configu- 
ree lors de la mise en ceuvre de ce type de module. Len-tete Web-DispatcherServletUrl Patterns 



L'outii dm Server 

Chapitre 17 



offre la possibilite de specifier un mappage specifique pour cette servlet, la valeur par defaut etant 
*.htm. 

Le code suivant decrit la maniere de configurer cet aspect (Q) dans le fichier MANI- 
FEST.MF du module : 

Module-Type: Web 
Web-ContextPath : tudu 

Web-DispatcherServletUrl Patterns: *.do<— Q 

La configuration de filtres servlet par l'intermediaire de l'en-tete Web-FilterMappings est un 
peu plus evoluee puisqu'elle necessite l'utilisation d'une ou plusieurs directives en comple- 
ment. La valeur specifiee pour le filtre correspond au nom du Bean relatif dans le contexte 
applicatif du module. Un parametrage peut etre ajoute afin de preciser, par exemple, les 
mappages relatifs a l'application du filtre par l'intermediaire de la directive url -patterns. 

Le code suivant decrit la configuration de deux filtres security Filter (Q) et imageFil ter Q) 
mappes avec les patterns *.do et *. jsp pour le premier et /image/* pour le second : 

Module-Type: Web 

Web-ContextPath : tudu 

Web-Di spatcherServl etUrl Patterns : *.do 

Web-Fi 1 terMappings : securi tyFi 1 ter ; url - patterns :="*.do,*. jsp" , <— © 
imageFi 1 ter ; url -patterns :="/ image/* "<—© 

Nous allons voir quels mecanismes dm Server propose afin de realiser une configuration plus 
avancee de l'application Web. 

Configuration Web avancee 

Pour ce type d' entite, dm Server offre la possibilite de specifier des elements de configuration 
Web dans un fichier web.xml classique optionnel. Les parametrages sont utilises en plus des 
elements specifies dans le fichier MANIFEST.MF par l'intermediaire des en-tetes decrits a la 
section precedente. 

Le fichier web.xml doit suivre la structure decrite dans la specification Servlet et se trouver 
directement sous le repertoire WEB-INF localise dans le repertoire MODULE-INF du 
composant. II offre la possibilite de specifier une configuration plus avancee que celle supportee 
par les en-tetes du fichier MANIFEST.MF. 



Fichiers PAR 

La derniere entite supportee par dm Server est le PAR (platform archive), qui correspond 
physiquement a un fichier jar avec l'extension PAR. Elle permet de mettre en ceuvre la notion 
d'application dans l'outii au sein meme de la technologie OSGi. 

Ce concept permet de regrouper dans une meme entite differents composants et modules rela- 
tifs a une application afin de les isoler du reste des entites presentes dans le conteneur OSGi. 

Une analogie peut etre faite entre l'entite ear (enterprise archive) contenant une application 
Java EE et l'entite PAR mettant en ceuvre un concept similaire dans le cadre de la technologie 
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OSGi. La principale difference consiste en la possibilite de rafraichir independamment et 
dynamiquement ses differents constituants a F execution. 

Un PAR possede la particularite d'etre visible au sein des outils d' administration de dm 
Server et peut etre manipule a ce niveau afin de realiser facilement des operations de deploie- 
ment et d' administration. 

Concretement, un fichier PAR comprend 1' ensemble des composants et modules constituant 
F application ainsi qu'un parametrage par l'intermediaire du fichier MANIFEST.MF present 
dans le repertoire META-INF. Afin de configurer l'entite, differents en-tetes specifiques sont 
disponibles, comme le recapitule le tableau 17-5. 



Tableau 17-5. En-tetes utilisables dans le fichier MANIFEST.MF d'un fichier PAR 



En-tete 


Description 


Appl i cation -Symbol i cName 


Permet de specifier le nom symbolique de I'application contenue dans le PAR. 


Appl i cation -Name 


Permet de specifier le nom de I'application contenue dans le PAR. 


Appl i cat ion -Vers ion 


Permet de specifier la version de I'application contenue dans le PAR. 


Appl i cat ion -Description 

. 


Permet de specifier la description de I'application contenue dans le PAR. 



Le code suivant fournit un exemple de configuration d'un fichier PAR issue de F etude de cas 
Tudu Lists : 

Manifest-Version: 1.0 

Appl i cati on -Name: tudu -appl i cati on 

Application-Version: 1.0.0 

Appl i cati on -Symbol icName: tudu_appl i cati on 

Application-Description: Application Todo Lists 

Avec le concept de PAR, dm Server offre une interessante fonctionnalite pour utiliser la technolo- 
gie OSGi. Au sein des entites regroupees dans un PAR, il est possible de charger n'importe quelle 
classe contenue dans des packages exposes par l'intermediaire du traitement Class.forName ou 
d'un equivalent. Comme nous l'avons vu au chapitre precedent, cette possibilite est toutefois 
source de problemes de chargement de classes avec la technologie OSGi seule. 



En resume 

Loutil dm Server propose differentes possibilites pour structurer des applications en son sein 
en se fondant sur differentes unites de deploiement, pour lesquelles il offre une grande flexibi- 
lite quant a leur utilisation. 

Loutil supporte les applications Web classiques, tout en offrant differents degres d' utilisation 
de la technologie OSGi. II est possible de ne pas l'utiliser du tout, de la mettre en ceuvre afin 
de gerer les dependances de I'application ou de se fonder sur les services OSGi exposes par 
des composants afin de realiser des traitements. 

Puisque dm Server integre un conteneur OSGi, il supporte bien evidemment les composants 
OSGi classiques, mais apporte en parallele un type de composant oriente Web. Ce dernier 
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fournit des fonctionnalites pour realiser des traitements permettant notamment de configurer 
implicitement Spring et Spring MVC au moment de son chargement. 

L'outil permet enfin de mettre en oeuvre des applications au sein d'un conteneur OSGi par 
l'intermediaire du support des par. Ces derniers permettent de regrouper des composants, tout 
en les isolant des autres composants presents dans le conteneur. 



L'outil dm Server correspond veritablement a un serveur d' applications de nouvelle genera- 
tion. II offre une veritable plate-forme integrant des conteneurs Web et OSGi ainsi que diffe- 
rents outils permettant d'administrer ces conteneurs ainsi que les entites contenues. 

Installation et mise en oeuvre 

L'outil dm Server est propose sous licence GPL version 3. II est telechargeable sur le site de la 
societe SpringSource a la rubrique « Produits », a l'adresse http://www.springsource.com/ 
products/suite/dmserver. Sont accessibles a ce niveau des versions pour les systemes d'exploita- 
tion Windows et Linux. 

Sur les deux systemes, 1' installation de l'outil consiste simplement en 1' extraction du contenu 
de 1' archive dans le repertoire de notre choix. Une fois cette operation realisee, il est conseille 
de creer une variable d'environnement referencant le repertoire d' installation, mais ce n'est 
pas obligatoire. 

L'utilisation du nom SERVERJOME pour cette variable est suggeree. Sous Linux, cela se realise 
en utilisant la commande export dans le fichier .profile de l'utilisateur courant. Sous 
Windows, la configuration se realise par l'intermediaire des « proprietes systeme » en selec- 
tionnant le bouton « variables d'environnement » dans l'onglet « Avancee ». II convient alors 
de creer une nouvelle variable avec le nom precedent. 

Le demarrage et F arret du serveur se fondent respectivement sur les scripts startup.sh et 
shutdown.sh sous Linux et startup.bat et shutdown.bat sous Windows. Ces scripts sont 
presents dans le sous-repertoire bin de la distribution. 

Le message (©) decrit dans le code suivant s'affiche dans la console de lancement afin de 
signaler un demarrage avec succes de l'outil : 



$ bin/startup. sh 

[2008-10-25 10:26:42.176] main <SPKB0001I> Server starting. 

[2008-10-25 10:26:46.413] main <SP0F0001I> OSGi telnet console available on 



[2008-10-25 10:26:56.526] server-dm- 14 <SPPM0000I> Installing profile 'web'. 

[2008-10-25 10:26:58.821] server-dm-8 <SPSC0001I> Creating HTTP/1.1 connector with 

scheme http on port 8080. 

[2008-10-25 10:26:58.835] server-dm-14 <SPPM0001I> Installed profile 'web'. 

[2008-10-25 10:26:58.976] server-dm-8 <SPSC0001I> Creating HTTP/1.1 connector with 



Plate-forme 



port 2401. 

[2008-10-25 10:26:53.595] main 
[2008-10-25 10:26:54.330] main 



<SPKE0000I> Boot subsystems installed. 
<SPKE0001I> Base subsystems installed. 
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scheme https on port 8443. 

[2008-10-25 10:26:58.999] server-dm-8 <SPSC0001I> Creating AJP/1.3 connector with 
scheme http on port 8009. 

[2008-10-25 10:26:59.056] server-dm-8 <SPSC0000I> Starting ServletContainer. 
[2008-10-25 10:27:00.586] server-dm-13 <SPPM0002I> Server open for business with 
profile 'web'.<— Q 

Une fois le serveur demarre, ce dernier deploie les differents composants, modules et applications 
presents. L' application d' administration de Foutil est chargee a ce moment. 

Le tableau 17-6 recapitule les differents arguments utilisables lors du lancement du serveur. 



Tableau 17-6. Arguments utilisables lors du lancement du serveur 



Argument 




Description 


-cl ean 




Active un nettoyage du serveur au demarrage en supprimant le repertoire wo r k ainsi que 
les fichiers de trace, de log et de dump. 


-debug <-suspend> 




Active le debogage du serveur en demarrant un agent de debogage. Un port peut etre 
specifie apres I'argument afin de definir le port d'ecoute de I'agent. Par defaut, ce port 
est 8000. L'utilisation conjointe de I'argument -suspend permet de suspendre I'execu- 
tion de la machine virtuelle tant qu'un debogueur ne s'y est pas attache. 


- jmxremote 




Active un service JMX pour le serveur. Un port peut etre precise apres I'argument afin 
d'autoriser les connexions distantes, tout en definissant le port d'ecoute du service. Si 
aucun port n'est specifie, seules les accroches locales sont autorisees. 


Concernant 1' arret du serveur, le message (Q) decrit dans le code suivant s'affiche dans la 
console de lancement en cas de succes : 


[2008-10-25 10:37 
[2008-10-25 10:37 
ServletContainer. 


: 53.802] eduled-executor-thread-1 <SP0F0004I> Shutdown initiated. 
: 53.871] server-dm-10 <SPSC0002I> Shutting down 



L' option - immediate est utilisable dans ce contexte afin d'arreter immediatement le serveur en 
outrepassant le cycle normal d' arret. 



Gestion du depot 

Le depot local de dm Server regroupe tous les composants et bibliotheques potentiellement 
utilisables par le serveur aussi bien que par les composants applicatifs et les applications qu'il 
contient. 

Par defaut, le depot est localise dans le sous-repertoire repository de la distribution et est 
structure en deux repertoires, bundles pour les composants et libraries pour les bibliotheques. 
Pour chacun de ces repertoires, sont presents les deux sous-repertoires suivants : 

• ext, contenant des entites externes fournies directement dans la distribution de Foutil ; 

• usr, contenant des entites externes ajoutees par Futilisateur ou le developpeur pour les 
besoins de ses composants ou applications. 
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Dans le cas des composants, la presence d'un sous-repertoire subsystems contenant les 
composants utilises en interne par l'outil est necessaire. 

Pour installer un composant, il suffit de copier son fichier jar dans le repertoire bundles/usr. 
Pour une bibliotheque, la meme operation se realise avec le descripteur correspondant dans le 
repertoire libraries/usr. 

Afin d'approvisionner ce depot local, il est recommande d'utiliser le depot de SpringSource 
propose a Fadresse http://www.springsource.com/repository. Ce depot contient un ensemble de 
bibliotheques et frameworks Java et Java EE adaptes a une utilisation dans un environnement 
OSGi, et done dans dm Server. Ce depot presente Favantage d'integrer le concept de biblio- 
theques introduit par l'outil. 

En complement, une interface Web offre la possibilite de parcourir le depot et de realiser des 
recherches aussi bien au niveau des composants que des bibliotheques. Pour chaque page de 
description, les informations ainsi que les dependances des entites sont detaillees. 

Administration et deploiement 

L'outil dm Server propose deux approches distinctes pour le deploiement d'un composant ou 
d'une application. 

L'outil supporte le deploiement a chaud d'entites en se fondant sur la presence de fichiers dans le 
repertoire pickup de la distribution. Une fois une entite de ce type copiee dans ce repertoire, 
l'outil tente de la deployer. En cas de succes, le message suivant apparait dans les traces : 

[2008-11-04 14:50:35.686] fs-watcher <SPDE0010I> Deployment of tudu' version '1.0.0' completed. 

Dans le cas contraire, le message d'erreur correspondant est ecrit dans les traces. 

Une autre approche consiste a utiliser 1' application Web d' administration de dm Server. Cette 
derniere est accessible a l'adresse http://<machine>:<port>/admin, ou machine correspond au 
nom de la machine sur laquelle est installe l'outil, et port au port d'ecoute correspondant. 

Une section de l'interface Web est dediee au deploiement d'entites. II suffit pour cela de speci- 
fier une archive supportee par l'outil et de lancer le deploiement. 

La figure 17-7 illustre le deploiement de 1' application Tudo Lists par l'intermediaire du fichier 
tudu.par. 



Deploy an Application 



Select an application or bundle to upload and deploy to the server Valid file formats: jar. war. par. 



1/home/templth/developpement/eyrolles/tuduAudu.par |[ Parcourir i| | upload 



Figure 17-7 

Deploiement de I 'application Tudo Lists par l'intermediaire de l'interface graphique 
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Une fois F operation terminee, l'application deployee (ici Tudo Lists) apparait dans la liste des 
applications contenues dans l'instance du serveur, comme l'illustre la figure 17-8. 



Deployed Applications 



Name Version 

com. spring source serve rservlet. splash 0 


Origin 

1 lot Deployed 


Dale 

4 nov. 2000 
15:01:41 OCT 


Undeploy 

undeploy 


ft Associated Modules: 

com.springsource.server.servlet.splash (type: WAR) 


/ 






(.oiii upriipy&uuiLe server seivlel. jdtiuii 1 0 0 RELEASE 


Hul DepluyeU 


4 IKIV. 2008 
15.01 42 CET 


ui (deploy 


ft 1 Associated Modules: 

com. spring source server.servlet. admin (type: Web) 


'admin 






tudu_ap plication t 


fite:.nomeiempitn'Oeveioppernent applications sprlngsource- 
am-server-i .0.0 release. stage/iudu- application par 


4 nov. 2008 
15:01 :45 CET 


undeploy 


ft' Associated Modules: 

tudu web (type: Web) 
tudu application-synthetic .context (type: Bundle) 
tudu core (type: Bundle) 
tudu datasource (type: Bundle) 


.■ludu 

No personality idenlifer 
No personality idenlifer 
No personality idenlifer 







Figure 17-8 

Liste des applications deployees dans dm Server 

Traces applicatives 

L'outil dm Server est concu pour fournir des traces applicatives pertinentes dans le but de 
diagnostiquer facilement d'eventuels problemes et de gerer un volume important de traces. 

L'outil supporte deux types de sorties pour les traces : 

• Une sortie globale contenant toutes les traces relatives aux evenements et fonctionnements 
internes de l'outil. II offre ainsi la possibilite de diagnostiquer les erreurs d' execution. 

• Une sortie par application contenant toutes les informations de traces ecrites par cette 
derniere en se fondant sur les frameworks populaires de traces ainsi que sur les sorties standard 
et d'erreur. 

Dans les deux cas, les implementations de SLF4J relatives a Commons-Logging et Log4j sont 
utilisees afin de permettre l'ecriture de ces traces applicatives. 

Dans le premier cas, les traces applicatives sont ecrites dans le fichier de traces globales 
trace.log, localise directement sous le repertoire des traces. Dans le second, ces demieres 
sont ecrites dans le fichier precedent, mais egalement dans un fichier de traces nomme egale- 
ment trace.log et localise dans un sous-repertoire du repertoire de traces dont le nom est de 
la forme <nom-appl i cation>-<version-appl ication>. 

La figure 17-9 illustre les differents fichiers de traces presents dans une instance de dm Server 
dans laquelle est deployee l'application Tudu. 

D'une maniere generale, le format des traces applicatives est de la forme: <estampille 
temporel 1 e> <nom du thread courant > <source> <niveau> <message>. 
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Serviceability Destinations 



Nam* - 

togging 


Destination 

.''home/templth'devetoppement'ap plication sspringsource-dm-server-1 .0.0R EL EASE/servrce ability 
logs logging. tog 


trace 


hornelernplth de ve to ppernent'ap plicate .0.0 riCLCAOC. serviceability 
trace /trace log 


If ace corn.springsource.server,servtel.admin- 
1.0.0 .RELEASE 


/home/ternplthdevetoppernentap plication sspringsource-dm- server- 1 .0.0 RELEASE/ service ability 
trace corn springsource.server.servleLadrnin-1 0.0 RELEASEIrace tog 


trace -com. 3 prirxjoourcc server, a ervtct.opkish-O 


/rwrnc/templthacvctopp^rncntoppliCQtiono.spnngaourcc dm server 1 .0.0 RELEASE serviceability 
trocc'corn.apringaourcc.servcr.acrvlcLaplaah 0 trace log 


trace-ludu application- 1 


home.templthdevetoppement'ap plication sspringsource-drn- server- 1 .0.ORELEASE/serviceability 
trace tudu_appltcation-1 irace.log 



Figure 17-9 

Fichiers de traces presents dans une instance de dm Server 



Le code suivant decrit un exemple de fichier de trace avec des lignes provenant d'un outil de 
traces applicatives (Q), de la sortie standard (Q) et de la sortie d'erreur (©) : 

[2008-10-25 10:26:58.999] server-dm-8 <SPSC0001I> Creating AJP/1.3 connector with 

scheme http on port 8009. 

(...) 

[2008-05-16 09:28:45.874] server-tomcat-thread-1 System. out I Ecriture sur la sortie 

standard<— Q 

(...) 

[2008-05-16 09:28:45.874] server-tomcat-thread-1 System. err E Ecriture sur la sortie 
d 'erreur<— Q 

L'outii dm Server supporte un mecanisme de rotation des fichiers de traces qui garantit une 
taille de fichiers inferieure a 100 Mo. 



Configuration avancee 

Les configurations avancees du serveur d' applications et de ces differentes briques se realisent 
par l'intermediaire du fichier server.config localise dans le sous -repertoire config de la distri- 
bution. 

Dans ce fichier, tous les chemins sont relatifs par rapport a la racine de la distribution du 
serveur, et le contenu du fichier suit le format JSON. Ce format correspond a une representa- 
tion litterale d'objets utilisee notamment par JavaScript. 

Nous allons a present detailler les differentes sections de configuration presentes dans ce 
fichier. 

Traces et logs 

Comme le montre le code suivant, dm Server offre la possibilite de specifier les repertoires 
relatifs aux traces (Q), aux logs (Q) ainsi qu'aux fichiers de dump (©) : 

"trace": {<— Q 

"di rectory" : "serviceabil ity/ trace" 
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) 

"logs": {<— Q 

"di rectory" : "servi ceabi 1 i ty/1 ogs" 

} 

"dump": {<— Q 

"di rectory" : "servi ceabi 1 i ty/dump" 

} 

Tomcat 

L'outil dm Server permet de configurer finement les proprietes du conteneur Web Tomcat utilise 
en interne. Comme precedemment, cette configuration est au format JSON. Elle permet de confi- 
gurer des proprietes telles que les connecteurs et des informations relatives aux traces. 

Une fonctionnalite interessante de cette approche consiste en la possibilite d'activer ou de 
desactiver des blocs de configuration tout en les laissant presents dans le fichier. 

Le tableau 17-7 recapitule les proprietes de configuration utilisables a ce niveau. 



Tableau 17-7. Proprietes de configuration de Tomcat 



Propriete 




Description 


version 




Version du schema de configuration. 


configDir 




Repertoire de configuration du conteneur de servlets. 


hostName 




Specifie le nom de I'hote a utiliser par defaut. 


jvmRoute 




Specifie un nom unique pour le conteneur dans le cadre de la configuration 
du load balancing. 


1 i steners 




Specifie une liste d'observateurs sur le cycle de vie du conteneur. 


connectors 




Specifie une liste de connecteurs pour le conteneur. 


logs - accessLogDir 


Specifie le chemin du repertoire contenant les traces relatives aux acces au 
conteneur. 


logs - accessLogFormat 


Specifie le format des traces a utiliser. 


threadPool 


minSize 


Specifie le minimum de fils d'execution a garder dans le pool du conteneur. 


threadPool 


maxSi ze 


Specifie le maximum de fils d'execution a garder dans le pool du conteneur. 


threadPool 


keepAl i vePeri od 


Correspond au temps pendant lequel un thread inactif reste eveille dans le 
pool du conteneur. 



Le code suivant illustre un extrait d'une configuration typique du moteur Tomcat dans dm 
Server en se fondant notamment sur les proprietes 1 i steners (Q), connectors (Q), logs (©) et 
threadPool (©) decrites au tableau 17-7 : 

{ 

"servletContainer": { 
"version": 1.0, 

"conf igDi r" : "conf ig/servl et" , 
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"hostName": "local host", 
"jvmRoute": "jvml", 
"listeners": [<— O 
{ 

// Chargeur de la bibliotheque APR. 
"enabled": true, 

"cl assName" : "org. apache. catal ina . core<— Q 
.Apr Li fecycl eListener" , 

"SSLEngine": "on" 
}, { 

// Initialisation de Jasper, 
"enabled": true, 

"class Name" : "org. apache. catal ina .core. Jasper Listener" 

} 

], 

"connectors": [<— Q 
{ 

// Connecteur HTTP, 
"enabled": true, 
"port": 8080, 
"protocol": "HTTP/1.1". 
"connectionTimeout" : 20000, 
"maxThreads": 150, 
"emptySessionPath" : false, 
"redi rectPort" : 8443 
}, { 

// Connecteur HTTPS. 
"enabled": true, 
"port": 8443, 
"protocol": "HTTP/1.1", 
"scheme": "https", 
"connectionTimeout": 20000, 
"maxThreads": 150, 
"emptySessionPath": false, 
"clientAuth": false, 
"keystoreFi 1 e" : "keystore", 
"keystorePass" : "changeit", 
"secure": true, 
"SSLEnabl ed" : true, 
"ssl Protocol " : "TLS" 
}, { 

// Connecteur AJP. 
"enabled": true, 
"port": 8009, 
"protocol": "AJP/1.3", 
"connectionTimeout": 20000, 
"redi rectPort" : 8443 

} 
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"logs": {^0 

"perAppl i cat ion Logging" : true, 
"accessLogDi r" : "access", 
"accessLogFormat" : "long" 



"threadPool ": {<— Q 
"minSize": 25, 
"maxSize": 200, 
"keepAlivePeriod": 60000 



Le moteur Tomcat de dm Server peut etre parametre en se fondant sur la configuration au 
format JSON afin de mettre en ceuvre le load balancing ainsi que la « clusterisation ». 



Le code suivant montre comment configurer la console OSGi associee au conteneur Equinox. 
Les parametrages correspondants sont son activation ou sa deactivation (Q) ainsi que la 
specification du port d'acces (Q) : 

"osgiConsole" : { 

"enabled" : true,<— Q 
"port" : 24OK-0 

} 



La configuration de la localisation du depot de composants et de bibliotheques se realise au 
niveau de l'entree provi si onni ng. Cette derniere permet de specifier les chemins de recherche 
utilisables afin de resoudre les composants et les bibliotheques. 

Le code suivant montre la configuration par defaut qui se refere aux repertoires decrits prece- 
demment a la section « Gestion du depot » : 

"provisioning" : { 
"searchPaths" : [ 



"reposi tory/bundl es/subsystems/{name}/{bundl e} . jar" , 
"reposi tory/bundl es/ext/ {bundle} " . 
"reposi tory/bundl es/usr/ {bundle} " . 
" reposi to ry/1 i bra ri es/ext/ {1 ibrary}" , 
"repository/1 i brari es/usr/ {1 ibrary}" 



Ce type de configuration permet d'utiliser directement des variables systeme ainsi que des 
expressions de chemins en suivant le style de celles de l'outil Ant. Pour ces dernieres, les 
symboles * et ** sont supportes afin de representer respectivement un repertoire ou une suite 
de repertoires. 



Equinox 



Depot 



} 
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En se fondant sur ces elements de configuration, il est possible d'utiliser des depots locaux de 
Ivy ou Maven lors de la recherche des composants et des bibliotheques utilises. 

Le code suivant illustre la configuration du depot de dm Server pour l'utilisation d'un depot 
local Ivy : 

"provisioning" : { 
"searchPaths" : [ 

"reposi tory/bundl es /subsystems/ {name} /{bundle} . jar" , 
"reposi tory/bundl es/ext/{bundl e} " , 

"$ {user. home}/ . i vy2/cache/ {org} /{name} /{version} /{bundl e} . jar" , 
" reposi to ry/1 ibraries/ext/{l ibrary}" . 
"reposi to ry/1 i braries/usr/{l ibrary} " 

] 

} 

Le code suivant illustre la configuration du depot de dm Server afin d'utiliser un depot local 
Maven : 

"provisioning" : { 
"searchPaths": [ 

"reposi tory/bundl es /subsystems/ {name} /{bundle} . jar" , 

"reposi tory/bundl es/ext/ {bundl e} " , 

"${user . home}/ . ma ven/ reposi to ry/**/ {bundl e} . jar" , 

"reposi to ry/1 i brari es/ext/ {1 ibrary} " , 

"reposi to ry/1 i brari es/usr/{l ibrary}" 

] 

} 



Mise en oeuvre de dm Server dans Tudu Lists 

Dans le cadre de notre etude de cas, une version allegee de l'application Tudu Lists est mise 
en oeuvre, comme au chapitre precedent, avec une structuration en trois modules distincts, en 
adequation avec les differents mecanismes et couches applicatives. Ces dernieres correspon- 
dent globalement a des traitements permettant respectivement d'acceder aux donnees et de les 
afficher dans une interface Web. Les technologies Spring MVC et Hibernate ont ete choisies 
pour cette version de l'application. 

Les quatre composants suivants permettent de mettre en oeuvre l'application Tudo Lists avec 
dm Server : 

• Composant OSGi mettant a disposition un service relatif a la source de donnees afin d'acceder 
a la base de donnees utilisee. 

• Composant OSGi d'acces aux donnees permettant de gerer 1' interaction et l'utilisation de la 
base de donnees en se fondant sur le service de source de donnees precedent. 

• Composant OSGi de presentation des donnees au travers d'une interface graphique Web. 
L'interaction avec la base de donnees se realise par 1' intermediate des services mis a dispo- 
sition par le composant precedent. 
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• Composant par permettant de regrouper les composants precedents en une application, 
cette derniere etant accessible par F intermediate des entites du composant OSGi Web. 

Les traces applicatives sont prises en compte directement par dm Server. 

La figure 17-10 illustre les relations de ces differents composants. 



Figure 17-10 

Relations entre les 
composants OSGi de 
['application Tudu 
Lists 



8 



E = 



dm Server 



Composant PAR de I'application 



Composant Interface 
graphique Web 



Composant Acces 
aux donnees 



Composant Source 
de donnees 



Depot de composants et de bibliotheques 



Spring 



Hibernate 



Pool 



JSP/JSTL 



SpringSource Dynamic Modules Kernel 



Configuration du depot 

Pour nos besoins, il est necessaire d'ajouter differentes entites dans le depot local associe au 
serveur dm Server afin de pouvoir utiliser Hibernate, le pool de connexions DBCP d' Apache 
ainsi que la base de donnees HSQLDB. 

Le tableau 17-8 recapitule les entites a ajouter dans le depot du serveur dm Server pour nos 
besoins. 

Tableau 17-8. Dependances des entites a ajouter dans le depot de dm Server 



Dependance 


Type 


Description 


Pilote de base de donnees (HSQLDB) 


Composant 


com. springsource.org. hsql db (1 .8.0.9) 


Pool de connexions 


Composant 


com. spri ngsource.org. apache. commons. dbcp (1.2.2) 



Hibernate 3.3.2 Bibliotheque org. hibernate. ejb (3.3.2. GA) 



Ces elements doivent etre copies respectivement dans les repertoires repository/bundles/usr 
et repository/libraries/usr pour les composants et les bibliotheques. La bibliotheque Spring 
etant deja presente dans Foutil, elle n'a pas a etre ajoutee. 
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Composant source de donnees 

A Finstar de ce qui se fait avec OSGi, il est recommande de dedier un composant OSGi afin 
de mettre a disposition la source de donnees JDBC en se fondant sur un service exposant 
l'interface DataSource. 

Nous allons a cet effet utiliser l'outil DBCP, qui permet de creer un pool de connexions imple- 
mentant l'interface DataSource en se fondant sur les parametres classiques JDBC, a savoir le 
nom de la classe du pilote, l'adresse de la base de donnees ainsi que les identifiant et mot de 
passe d'acces. 



Utilisation de pools dans dm Server 

Dans sa version 1 .0 GA, dm Server ne supporte pas les fragments OSGi. Cela pose un probleme, notam- 
ment afin de specifier un pilote JDBC pour un composant relatif a un pool, ainsi que nous I'avons vu au 
chapitre precedent avec l'outil C3P0. 

Afin de contourner ce probleme, SpringSource a adapte le composant relatif au pool DBCP afin que ce 
dernier recherche egalement la classe du pilote dans le chargeur de classe du thread courant. Ainsi, I'utili- 
sation de ce pool devient possible sans avoir recours aux fragments puisque le pilote est visible pour ce 
chargeur. 



Pour definir le pool de connexions, nous allons utiliser la classe BasicDataSource de DBCP, 
cette derniere devant etre configuree en tant que Bean dans le fichier de configuration Spring 
du composant. Puisque cette classe possede des methodes d' initialisation et de finalisation, les 
attributs i nit -method et des troy -met hod doivent etre respectivement utilises lors de sa configu- 
ration. 

Le code suivant illustre la configuration (Q) de cette entite ainsi que son enregistrement (Q) 
en tant que service OSGi : 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 
xmlns:xsi=" http://www.w3.org/2001/XMLSchema -instance" 
xml ns :osgi="http: //www. springframework.org/schema/osgi " 
xsi :schemal_ocation=" 

http: //www. springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans .xsd 

http: //www. springframework.org/schema/osgi 
http://www.springframework.org/schema/osgi/spring-osgi .xsd"> 

<bean id="propertyConfigurer" 

cl ass-" org. spri ngframework. beans .factory . config. 

Property PI aceholderConf igurer"><— Q 
<property name="location" val ue="jdbc.properties"/> 
</bean> 



<!-- Source de donnees --> 
<bean id="dataSource" 



Spring en production 

Partie V 



cl ass-" org. apache. commons .dbcp. Basi cDataSource"<— Q 
ini t -method-" createDataSource " des troy -met hod="close"> 
<property name="dri verCl assName" 

val ue="${ jdbc.dri verCl ass Name } "/> 
<property name="url" value="${jdbc.url }"/> 
<property name="username" value="${jdbc.username}"/> 
<property name="password" val ue="${jdbc. password}"/) 
</bean> 



<!-- Enregi strement de la source en tant que service OSGi --> 
<osgi :service ref="dataSource"><— Q 
<osgi :interfaces> 

<val ue>javax. sql .DataSource</val ue> 
</osgi : i nterf aces> 
</osgi : servi ce> 
</beans> 

Remarquons dans ce code l'utilisation de la classe Property PI aceHolderConfigurer (0) qui 
permet d'externaliser les proprietes JDBC dans un fichier de proprietes jdbc.properties. Ce 
dernier doit etre present a la racine du classpath du composant. 

Le composant relatif a la source de donnees possede les dependances recapitulees au 
tableau 17-9. 



Tableau 17-9. Dependances du composant de la source de donnees 



Dependance 


Type 


Description 


Pilote de base de donnees (HSQLDB) 


Composant 


com.springsource.org.hsqldb (1.8.0.9) 


Pool de connexions 1 .2.2 


Composant 


com. springs our ce.org. apache, commons, dbcp (1.2.2) 


Spring 2.5.5 


Bibliotheque 


org. springframework. spring (2.5. 5.A) 



En complement de ces elements, le package javax.sql doit etre egalement importe afin de 
pouvoir utiliser l'interface DataSource de JDBC. 

Au vu des elements du tableau 17-9, le contenu du fichier MANIFEST.MF est le suivant : 

Manifest-Version: 1.0 
Bundle-Version: 1.0.0 
Bundle-Name: tudu-datasource 
Bundle-ManifestVersion: 2 
Bundl e- Symbol i cName: tudujatasource 

Import -Library: org.springf ramework.spring;version="2.5.5.A" 
Import-Bundle: com. springsource. org. hsqldb; version-" 1.8. 0.9", 
com. sp ringsource.org. apache. commons. dbcp; vers ion-" 1.2. 2" 
Import-Package: javax.sql 
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Composant d'acces aux donnees 

Une fois le composant relatif a la source de donnees mis en ceuvre, le composant d'acces aux 
donnees peut se fonder sur la source de donnees exportee afin d'interagir avec la base de donnees. 

Ce composant utilise comme precedemment les frameworks Hibernate et Spring afin de reali- 
ser respectivement les traitements d' interaction avec la base de donnees et d' avoir acces a des 
facilites d'utilisation dans les traitements. 

Avec dm Server, les packages utilises n'ont plus a etre specifies un a un. La fonctionnalite 
relative aux bibliotheques permet de les specifier d'un coup, les bibliotheques ayant directe- 
ment connaissance des packages necessaires. 

Le composant relatif a 1' acces aux donnees possede desormais les dependances recapitulees 
au tableau 17-10. 



Tableau 17-10. Dependances du composant d'acces aux donnees 



Dependance 


Type 


Description 




CGLib 2.1.3 


Composant 


com. springs our ce. net. sf .cglib (2.1.3) 




Spring 2.5.5 


Bibliotheque 


org.springframework. spring (2. 5. 5. A) 




Hibernate 3.3.2 


Bibliotheque 


org. hibernate. ejb (3.3.2.GA) 




AspectJ 1.6.1 


Bibliotheque 


org.aspectj (1.6.1) 





Comme pour le composant precedent, le package javax.sql doit etre importe en complement 
afin de pouvoir utiliser l'interface DataSource de JDBC, interface utilisee par le service OSGi 
relatif a la source de donnees. 

Le code des classes ainsi que la configuration XML de ces entites reste identique a celle du 
composant OSGi relatif a 1' acces aux donnees decrit au chapitre precedent (voir la section 
« Composant d'acces aux donnees »). 

Seul le contenu du fichier MANIFEST.MF change puisque dm Server propose de nouveaux 
en-tetes afin de configurer plus simplement les dependances dans un environnement OSGi. 

Au vu de ces elements et du tableau 17-10, le contenu de ce fichier est le suivant : 

Manifest-Version: 1.0 
Bundle-Version: 1.0.0 
Bundle -Name: tudu-core 
Bundle-ManifestVersion: 2 
Bundle-SymbolicName: tudu_core 

Import- Library: org.springframework.spring;version="2.5.5.A" , 

org.hibernate.ejb;version="3.3.2.GA" , 

org.aspectj ; vers ion=" 1.6.1" 
Export-Package: tudu. domain. model , 

tudu. service 

Import-Package: javax.sql 

Import -Bundle: com.springsource.net.sf .cgl ib; vers ion=" 2.1 .3" 
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Composant d'interface Web 

La mise en ceuvre du composant relatif a F interface Web differe du composant similaire dans 
un environnement OSGi simple. Avec dm Server, le type de module Web doit etre specifie par 
F intermediate de Fen-tete Module-Type. En parallele, les en-tetes de Foutil peuvent toujours 
etre utilises quant a la configuration des composants et des bibliotheques. 

Le composant relatif a Finterface Web possede les dependances recapitulees au tableau 17-11. 



Tableau 17-11. Dependances du composant Web 



Dependance 


Type 


Description 


Spring 2.5.5 


Bibliotheque 


org. springframework. spring (2.5. 5. A) 


JSTL 1.1.2 


Composant 


com.springsource. javax.servlet. jsp. jstl (1.1.2) 



Apache Standard Taglibs 1 .1 .2 Composant com.springsource.org. apache. tagl ibs .standard (1.1.2) 



Dans le cadre d'un composant de type Web, au sens de dm Server, un repertoire MODULE- 
INF contenant les elements relatifs a F application Web ainsi que le repertoire WEB-INF doit 
etre cree a la racine du composant. Dans notre contexte, les differents fichiers JSP sont localises 
dans un sous-repertoire du repertoire WEB-INF. 

Avec dm Server, il n'est pas necessaire de definir un fichier web.xml avec les differentes 
servlets de Fapplication. La servlet DispatcherServlet de Spring MVC est automatiquement 
ajoutee, son mappage etant par defaut *.htm . Cela peut toutefois etre modifie par Finterme- 
diaire de Fen-tete Web-DispatcherServletUrl Patterns. Dans notre cas, ce dernier est utilise 
afin de specifier le mappage * . do. 

Le code suivant illustre les elements contenus dans le fichier MANIFEST.MF afin de confi- 
gurer respectivement le type (Q) et le context (Q) du composant ainsi que le mappage (©) 
de la servlet de Spring MVC : 

(...) 

Module-Type: Web<— Q 
(...) 

Web-ContextPath: /tudu<— Q 
Web-DispatcherServletUrl Patterns : *.do^Q 

A Finstar du composant d'acces aux donnees, le reste des traitements reste similaire a ceux 
mis en ceuvre avec OSGi simple. La seule difference consiste en la localisation du ou des 
fichiers de configuration de Spring. Ces derniers sont desormais a placer dans le repertoire 
spring situe directement sous le repertoire META-INF. Leur chargement n'est plus desor- 
mais realise en se fondant sur les mecanismes standards des applications Web Spring, mais 
directement par dm Server. 

En se fondant sur les differents elements decrits dans cette section ainsi que sur le tableau 17-1 1, 
le contenu du fichier MANIFEST.MF du composant Web est le suivant : 

Manifest-Version: 1.0 
Module-Type: Web 
Bundle-Version: 1.0.0 
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Bundle-Name: tudu-web 
Bundle-ManifestVersion: 2 
Web-ContextPath : /tudu 
Web-DispatcherServletUrl Patterns: *.do 
Bundle-SymbolicName: tudu_web 

Import -Library: org.springf ramework.spring;version="2.5.5.A" 
Import -Package: javax.servlet.http;version="2.5.0" , 

tudu. domain. model , 

tudu. service 

Import - Bundl e: com.springsource. javax.servl et . jsp. jstl ; vers ion-" 1 . 1.2", 
com. spr i ngsource. org. apache. taglibs. standard; vers ion-" 1.1. 2" 

Les composants relatifs a JSTL doivent toujours etre inclus afin de pouvoir utiliser cette 
technologie dans les pages JSP. 



Composant par de /'application 

Avec dm Server, il est possible de regrouper un ensemble de composants dans une meme 
application, celle-ci pouvant etre deployee en une seule passe dans l'outii. Un fichier par est 
alors necessaire. Comme nous l'avons vu precedemment, ce fichier coiTespond a un compo- 
sant OSGi special contenant les differents composants relatifs a F application. 

Le fichier MANIFEST.MF de ce composant permet de preciser des informations relatives a 
1' application, comme dans le code suivant : 

Manifest-Version: 1.0 

Appl i cation -Name: tudu-appl i cation 

Application-Version: 1.0.0 

Appl i cation -Symbol icName: tudu_appl i cation 



En resume 

Nous avons vu comment mettre en ceuvre une application en se fondant sur des composants 
OSGi classiques ainsi qu'un module Web. Une application a egalement ete creee par l'inter- 
mediaire d'un fichier par afin de regrouper ces differents elements. 

Les mecanismes mis a disposition par dm Server ont permis d'apporter une reelle simplifica- 
tion de la configuration et de l'utilisation de la technologie OSGi. La gestion des dependances 
est simplifiee avec le concept de bibliotheque et la mise a disposition des nouveaux en-tetes 
Import-Bundle et Import-Library. 

Les modules Web permettent d'alleger la mise en ceuvre de Spring au sein d'un composant 
OSGi implementant des preoccupations Web. Le contexte applicatif est desormais charge 
implicitement, tout comme la creation de la servlet Di spatcherServl et de Spring MVC. 

En comparaison des applications fondees simplement sur Spring Dynamic Modules et decrites au 
chapitre precedent, l'outii offre concretement un apport pour mettre en ceuvre plus simplement 
des applications d'entreprise dans le contexte d'OSGi. 
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Conclusion 

L'outil dm Server offre de reelles facilites de mise en ceuvre d' applications d'entreprise tres 
modulaires en se fondant sur la technologie OSGi. L'outil enrichit cette derniere grace aux 
concepts de bibliotheques et d'applications. 

Les bibliotheques offrent une fonctionnalite permettant de mettre en ceuvre et d'utiliser des 
frameworks Java dans des composants OSGi. La complexity au niveau des dependances 
entrainait des erreurs difficiles a diagnostiquer ainsi que des difficultes a constituer un depot 
coherent de composants. La specification des packages necessaires est considerablement 
simplifiee puisque cette operation peut desormais etre realisee globalement, et non plus 
unitairement. 

L'outil dm Server offre egalement le support de differents artefacts permettant de structurer 
les applications d'entreprise et d'offrir des fonctionnalites relatives a differentes preoccupa- 
tions, notamment Web. Tous les mecanismes de Spring et Spring Dynamic Modules restent 
toujours utilisables dans ce contexte. 

En parallele, dm Server met a disposition un veritable serveur d'applications de nouvelle 
generation offrant une plate -forme legere et performante, adaptant les ressources utilisees en 
fonction des besoins. Un support est egalement propose afin de diagnostiquer rapidement les 
erreurs dm bien en developpement qu'en production. 

L'outil DM Server s'inscrit dans 1' effort de Spring consistant a positionner la technologie 
OSGi au sein des applications d'entreprise afin de beneficier de tous les avantages de cette 
derniere, que ce soit au niveau de la structuration des applications ou de leur administration a 
chaud a 1' execution. 
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La supervision offre un cadre normalise et homogene pour visualiser des informations relati- 
ves a une application et interagir avec son parametrage lors de son execution. Ces informa- 
tions peuvent etre visualisees a la demande de la console de supervision ou etre dispatchees 
par F application elle-meme. 

Les enjeux de la supervision sont aussi bien F augmentation de la disponibilite des applica- 
tions et de la reactivite face aux problemes d' execution que la facilitation du controle des 
systemes d' information. 

Java s'est tres vite oriente vers la supervision par le biais de la technologie JMX (Java Mana- 
gement extensions). L'objectif de JMX est de definir une architecture ainsi qu'un ensemble 
d' interfaces de programmation standards arm de superviser grace a ce langage des reseaux, 
des services et des equipements dont les composants peuvent etre ecrits dans divers langages. 

Nous entendons par supervision le fait d'acceder a des informations sur Fetat de composants 
a un moment donne de l'execution d'une application, ce qui est particuherement interessant 
pour determiner les causes des dysfonctionnements d'une application. 

Le succes de JMX est tel dans le monde Java/Java EE que cette technologie est desormais 
integree aux serveurs d' applications Java EE ainsi qu'a certains frameworks. Cette mise en 
ceuvre donne acces a des informations concernant les ressources utilisees et permet d'effectuer 
des operations d' administration durant l'execution des applications. 

Les specifications JMX 

Cette section presente F ensemble des specifications relatives a JMX et donne un aper5u de 
son architecture generale ainsi que des concepts mis en ceuvre. 
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La fin de la section traite des differentes implementations de JMX ainsi que des consoles JMX 
disponibles. 

La technologie JMX comporte plusieurs specifications differentes, notamment les deux 
suivantes, qui en decrivent les fondations : 

• JSR 3, en version 1.2 actuellement, qui concerne les concepts et 1' architecture de JMX. 

• JSR 160, qui etend la precedente et standardise la maniere d'acceder aux agents JMX 
depuis les applications de supervision compatibles JMX, englobant les aspects d'interope- 
rabilite, de transparence et de securite des acces. 

Une autre specification, la JSR 255, prend le relais des precedentes afin de decrire la 
version 2.0 de JMX, integree dans la version 6.0 de Java. Nous ne traitons pas de cette speci- 
fication dans cet ouvrage. 

Lobjectif des specifications JMX est de decrire la maniere de recuperer des informations 
concernant des ressources applicatives, d'interagir avec ces demieres et de declencher certai- 
nes operations. Ces ressources peuvent correspondre a des composants techniques, tels que 
des pools de connexions, mais egalement des composants d'une application ou d'un 
framework. 

JMX fournit un cadre robuste, qui permet de specifier finement les proprietes et actions acces- 
sibles des composants. La technologie propose egalement un mecanisme pour notifier les 
applications de supervision suite a des evenements. 

Architecture de JMX 

JMX a pour objet de standardiser la structuration des composants supervisables tout en les 
rendant accessibles aux outils de supervision. 

La specification met en ceuvre une architecture a trois niveaux, comme illustre a la 
figure 18-1. 

Figure 18-1 
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Le niveau le plus proche des ressources correspond a V instrumentation, dont l'objectif est de 
fournir une ressource supervisable. La specification JMX offre divers cadres techniques a cet 
effet, dont certains ont un impact sur les ressources. 
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La couche intermediate entre ces ressources et les outils de supervision gere les differentes 
ressources supervisables et est nominee agents. Les entites de cette couche permettent notam- 
ment d'associer un nom a une ressource supervisable, ainsi que des observateurs. 

Le niveau services distribues specifie l'acces aux ressources par les outils ou applications de 
supervision par le biais de differents protocoles ou connecteurs. 

Afin de decrire les differents MBeans JMX, nous allons commencer par introduire un exemple 
issu de Tudu Lists. Lobjectif est de superviser le composant applicatif d'identifiant 
datasource afin de visualiser et eventuellement de modifier ses proprietes. 

Ce composant est configure dans le fichier datasource-context.xml localise dans le repertoire 
WEB-INF : 

<bean id="dataSource" class-"org.springframework 

. jdbc. datasource. Dri verManagerDataSource"> 
<property name="driverCl assName" 

val ue="${ jdbc. dri verCl ass Name} "/> 
<property name="url " val ue="${jdbc.url }"/> 
<property name="username" value="${jdbc.username}"/> 
<property name="password" value="${jdbc.password}"/> 
</bean> 

Comme le montre le code ci-dessus, le composant possede les proprietes suivantes : 

• driverClassName, qui specifie la classe du pilote JDBC utilise. 

• url , qui definit l'adresse JDBC de la base de donnees utilisee. 

• username et password, qui specifient respectivement 1'identifiant et le mot de passe de l'utili- 
sateur. 

Les valeurs de ces proprietes sont deffnies dans le fichier hibernate.properties localise dans 
le repertoire WEB-INF : 

(...) 

jdbc. dri verCl assName=com.mysql .jdbc. Dri ver 

jdbc .url=jdbc:mysql : //l ocal host: 3306/ tudu 

jdbc.username=root 

jdbc.password= 

(...) 

Le niveau instrumentation 

Le MBean (Managed Bean) est l'entite de base de JMX. II definit un cadre de conception afin 
qu'un serveur de supervision compatible JMX puisse determiner ou positionner la valeur 
d'une propriete ainsi qu'appeler une methode d'un composant applicatif. 

JMX decrit quatre types de MBeans, qui repondent a des regies de mise en ceuvre variees, 
adaptees aux divers besoins des applications en termes de fonctionnalites et de complexite. 
Ces differentes regies doivent etre strictement suivies afin que les MBeans soient compati- 
bles JMX. Remarquons que, dans le cas contraire, ils sont consideres comme incompati- 
bles. Dans ce cas, une exception de type NotCompl i antMBeanException est levee lors de leur 
enregistrement. 
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La validite de ces regies est verifiee par le serveur de MBeans au moment de l'enregistrement 
en utilisant les mecanismes d' introspection de Java. 

Le tableau 18-1 recapitule les differents types de MBeans specifies par JMX. Nous les decri- 
vons plus en detail a la section suivante. 



Tableau 18-1. MBeans specifies par JMX 


Type 


Description 


StandardMBean 


Type de MBean le plus simple, il s'appuie sur une interface utilisateur afin de determiner les 
metadonnees a exposer dans JMX. 


DynamicMBean 


Bend le type de MBean precedent afin de rendre dynamique la determination des metadon- 
nees. II s'appuie sur une interface definie par la specification JMX. 


ModelMBean 


Permet de specifier les metadonnees a exposer dans JMX par I'intermediaire d'interfaces et 
de classes de JMX sans impacter le composant. 


OpenMBean 


Bend le type de MBean precedent afin d'adresser des utilisations avancees de JMX. 



Les differents types de MBeans 

JMX propose divers types de MBeans aux caracteristiques differentes et ayant plus ou moins 
d'impact sur l'architecture et les composants eux-memes. 

Le premier type de MBean, StandardMBean, se distingue par sa simplicite. Seule la mise en 
ceuvre d'une interface specifique est necessaire pour decrire les proprietes et methodes acces- 
sibles par JMX. Le Bean a superviser doit imperativement implementer cette interface. De ce 
fait, il se trouve lie explicitement a la specification, sauf a recourir a la POA, qui permet 
d'ajouter cette interface a la classe de maniere transparente. 

L interface doit respecter certaines conventions decrites par la specification JMX. De ce fait, 
elle doit etre codee pour un composant specifique, et son nom doit etre suffixe par MBean. Au 
travers de cette interface, ce dernier definit les proprietes et methodes exposees dans JMX. 
Remarquons que ces proprietes sont mises en ceuvre grace a des accesseurs et des modifica- 
teurs. Si Faccesseur est omis, la propriete est en lecture seule. Inversement, si le modificateur 
est omis, la propriete est uniquement disponible en ecriture. 

Comme la classe DriverManagerDataSource est non pas une classe de l'application, mais une 
classe du support JDBC de Spring, nous ne pouvons pas la modifier. Nous devons done creer 
une sous-classe afin de lui ajouter des methodes et implementer Finterface JMX. 

Nous nommons cette sous-classe JmxDriverManagerDataSource et la configurons dans le 
fichier de configuration datasource-context.xml de la maniere suivante : 

<bean id="dataSource" cl ass-" tudu. jmx. JmxDri verManager Data Source "> 

<property name="driverCl assName" 

val ue="${ jdbc.driverClassName} "/> 

<property name="url" val ue="${jdbc.url }"/> 

<property name="username" value="${jdbc.username}"/> 

<property name="password" value="${jdbc.password}"/> 
</bean> 
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Le code suivant decrit l'interface que le composant doit implementer pour definir les proprie- 
tes et methodes exposees dans JMX : 

public interface JmxDriverManagerDataSourceMBean 
String getDriverClassName( ) ; 
Stri ng getUrl ( ) ; 

String getUsername( ) ; 

void setllsername(String username); 

String getPassword( ) ; 

void setPassword(String password); 

void resetO; 

} 

Comme le montre le code suivant, le composant doit implementer cette interface (Q) pour 
etre utilisable par JMX : 

public class JmxDriverManagerDataSource 

extends DriverManagerDataSource 

implements JmxDriverManagerDataSourceMBean {<— O 

public void resetO { (...) } 

} 

Notons que la propriete username est en lecture-ecriture, tandis que la propriete 
driverCl assName est en lecture seule. 

Ce type de MBean est contraignant, puisqu'il impose de se lier aux conventions JMX, et n'est 
done pas transparent pour 1' application. 

Le MBean DynamicMBean utilise le meme principe, mais permet en outre de decrire de maniere 
dynamique les proprietes et methodes exposees dans JMX par le biais de l'interface Dynami cMBean. 
Celle-ci est localisee dans le package javax. management et decrite de la facon suivante : 

public interface DynamicMBean { 

public Object getAttribute(String attribute) 

throws AttributeNotFoundException , 

MBeanException , Ref 1 ectionException ; 
public void setAttribute(Attribute attribute) 

throws AttributeNotFoundException , 

Inval idAttributeVal ueException, 

MBeanException , Ref 1 ectionException ; 
public AttributeList getAttributes(String[] attributes); 
public AttributeList setAttributes(AttributeList attributes); 
public Object invoke(String actionName, 

Object params[], String signature[]) 

throws MBeanException, ReflectionException; 
public MBeanlnfo getMBeanlnfot ) ; 

} 
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Cette interface utilise la classe MBeanlnfo du package javax. management, qui permet de decrire 
les metadonnees d'un MBean. Notons egalement dans le code ci-dessus F utilisation de la 
classe AttributeList du meme package afin d'etendre la classe Array List et d'empecher 
l'ajout d'instances autres que de type Attribute. Cette derniere permet de stacker une cle 
ainsi que sa valeur associee. 

Le composant doit implementer cette interface pour renvoyer les valeurs pour des noms de 
proprietes ainsi que les metadonnees du MBean. 

Le code suivant illustre la mise en ceuvre des methodes getAttri bute (Q) et i nvoke (Q) dans 
le composant precedent afin de le convertir en Dynami cMBean : 

public class JmxDriverManagerDataSource 

extends Dri verManagerDataSource 
implements Dynami cMBean { 



public void resetO { (...) } 

public Object getAttribute(String attribute)*— Q 

throws Attri buteNot Found Except ion , 
MBeanException, ReflectionException { 
if ( "dri verCl assName" .equal s(attri bute) ) { 

return getDri verCl assName( ) ; 
} else if ( "url " .equal s(attribute) ) { 

return getUrlO; 
} else if ( "username" .equal s(attri bute) ) { 

return getllsername( ) ; 
} else if ( "password" .equal s(attri bute) ) { 

return getPassword( ) ; 
} else { 

throw new AttributeNotFoundException( 
"L'attribut avec le nom "+attribute+ 
" n'existe pas pour le MBean"); 

} 

} 



public Object invoke(String actionName,<— Q 

Object params[], String signature[]) 
throws MBeanException, ReflectionException; 
if ("reset". equals(actionName)) { 
reset( ) ; 
return nul 1 ; 
} else { 

throw OperationsException( 

"L'action avec le nom "+actionName+ 
"n'existe pas pour le MBean"); 

} 

} 

} 
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Comme pour le premier type, l'utilisation de DynamicMBean est contraignante. Elle impose en 
effet de se Her aux API JMX, ce qui n'est pas transparent pour l'application (a moins d'utiliser 
laPOA). 

Le type Model MBean ouvre une perspective interessante pour creer un MBean sans impact sur 
le composant lui-meme en jouant un role de proxy. II permet de decrire les informations 
concernant les proprietes et methodes supervisees par l'intermediaire de F interface 
Model MBean de JMX, localisee dans le package javax. management, dont le code est le suivant : 

public interface ModelMBean extends DynamicMBean, 

Persi stentMBean , ModelMBeanNotificationBroadcaster { 
public void setModelMBeanInfo(ModelMBeanInfo inModelMBeanlnfo) 
throws MBeanException , RuntimeOperationsException; 
public void setManagedResource(Object mr, String mr_type) 

throws MBeanException, RuntimeOperationsException, 
InstanceNotFoundException , 
Inval idTargetObjectTypeException ; 

} 

Le developpement de ce MBean comporte les trois etapes suivantes : 

1, Instanciation du MBean par le biais de l'unique implementation Requi redModel MBean 
du package javax. management. modelmbean, fournie par la specification JMX. 

2. Definition des metadonnees du MBean par le biais de la classe ModelMBeanlnfo du 
package javax. management, comme dans le code suivant : 

//Creation de la description des attributs, des operations, 
//des constructeurs et des notifications du MBean 
ModelMBeanAttributeInfo[] attri butes 

- new ModelMBeanAttributeInfo[l] ; 

Descriptor champlDesc = new DescriptorSupport( ) ; 
champlDesc. setFiel d( "name" , "username" ) ; 
champlDesc. set Fi el d( "descriptorType" , "attribute" ) ; 
champlDesc. setFiel d( "di spl ay Name" , "Username" ) ; 
champlDesc. setFiel d( "getMethod" , "getUsername" ) ; 
champlDesc. setFiel d( "setMet hod" , "setUsername" ) ; 
champlDesc. setFiel d( "cur rencyTime Limit" , "20" ) ; 

attributes[0] = new ModelMBeanAttributelnfot 

"username" , "java . 1 ang. String" , 
"Description de Username. ", true , 
true.fal se, champlDesc) ; 

(...) 

Model MBeanOpe rat ionInfo[] operations 

- new ModelMBeanOperationInfo[0] ; 
Model MBeanConstructorInfo[] contructors 

- new ModelMBeanConstructor!nfo[0] ; 
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Model MBeanNotificati on Info[] notifications 

= new ModelMBeanNotificationlnfo [0]; 

//Creation de la description globale du MBean 

Descriptor descriptor = new DescriptorSupport(new String[] { 

"name=JmxDriverManagerDataSource" , "descriptorType=mbean" , 

"di spl ay Name=JmxDri verManager Data Source" , "1 og=T" , 

"1 ogf i 1 e=jmx. 1 og" , "currencyTimeLimi t=5" } ) ; 

//Creation du ModelMBeanlnfo pour 1 'ensemble du MBean 

String className = "JmxDriverManagerDataSource" ; 

String description = "Description du MBean sur MonComposant. " ; 

ModelMBeanlnfo info = new Model MBeanlnfoSupportt 

cl ass Name .description , attri butes , 
constructors .operations .notif i cations) ; 

dMBeanlnfo. setMBeanDescriptor(mmbDesc) ; 

3. Positionnement des metadonnees et rattachement du Bean au MBean lui-meme, 
comme dans le code suivant : 

JmxDriverManagerDataSource jmxDataSource = createDataSource( ) ; 

ModelMBean mbean = new Requi redModelMBeant ) ; 
mbean .setModel MBean Info (mbean Info) ; 

mbean .setManagedResource( jmxDataSource, "Object Reference" ) ; 

Notons qu'un autre type de MBean, OpenMBean, est reserve aux usages avances de JMX et 
n'est pas detaille dans ce chapitre. 

Le niveau agent 

Ce niveau specifie les differents composants de F infrastructure de JMX qui permettent de 
gerer les MBeans. Appeles agents ou serveurs JMX, ces composants offrent la possibilite 
d'enregistrer ou de desenregistrer les MBeans. 

Un MBean est identifie de maniere unique par un identifiant specifie au moment de son enre- 
gistrement dans le serveur de MBeans. Designe par le terme ObjectName, cet identifiant se 
presente sous la forme suivante : 

domai n-name : keyl=val uel[ , key2=val ue2 keyN=val ueN] 

L' element domai n-name symbolise le domaine du MBean. II est suivi d'une liste de cles- 
valeurs, qui permet de F identifier, avec, par exemple, une cle ayant pour valeur name. 

JMX fournit la classe ObjectName pour specifier cet identifiant. 
Recuperation du serveur de MBeans 

Un serveur de MBeans peut etre embarque dans F application ou fourni par F infrastructure 
dans laquelle fonctionne Fapplication, par exemple un serveur d' applications. 
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Dans le premier cas, il est explicitement cree au moyen de la classe JMX MBeanServerFactory 
et de sa methode createMBeanServer. Le code suivant en donne un exemple d'utilisation : 

MBeanServer server = MbeanServerFactory.createMBeanServer( ) ; 

Dans le cas d'un serveur JMX fourni par 1' infrastructure, une recherche du serveur s'impose. 
La classe MBeanServerFactory offre pour cela la methode findMBeanServer, qui prend en para- 
metre Fidentifiant de l'agent, c'est-a-dire du serveur. Ce parametre peut prendre la valeur 
nul 1 . Dans ce cas, tous les serveurs presents sont detectes. 

Le code ci-dessous en donne un exemple d'utilisation : 

List servers = MBeanServerFactory. findMBeanServer(agentld) ; 

Enregistrement de MBeans 

A partir des notions que nous venons de voir, nous pouvons deduire la facilite avec laquelle il 
est possible d'enregistrer un MBean. Cela s'effectue en utilisant le nom de la classe a enregis- 
trer ou une instance de celle-ci. L' interface MBeanServer, materialisant le contrat du serveur 
JMX, fournit pour cela les methodes createMBean et registerMBean. 

Le code suivant illustre la maniere d'enregistrer un MBean avec la methode registerMBean : 
MbeanServer server = getMBeanServer( ) ; 

ObjectName objName = new ObjectName( "MonDomain : Name=Test" ) ; 

Test test = new TestO; 

server. regi sterMBean(test , objName) ; 

Meme chose avec a la methode createMBean : 

MbeanServer server = getMBeanServer( ) ; 

ObjectName objName = new ObjectName( "MonDomai n : Name=Test" ) ; 
server. createMBeanC'package. Test" , objName) ; 

La methode unregi sterMBean permet de desenregistrer un MBean : 

j MbeanServer server = getMBeanServer( ) ; 

ObjectName objName = new ObjectName( "MonDomain : Name=Test" ) ; 
server . unregi sterMBean (objName) ; 

Le niveau services distribues 

Ce niveau specifie la facon dont les applications clientes de supervision peuvent se connecter 
au serveur JMX depuis l'exterieur. 

La specification decrit les deux approches suivantes pour cela : 

• Approche par adaptateur de protocole. Reduit l'impact de JMX sur les applications clientes 
en donnant acces aux composants JMX du serveur par le biais d'un protocole donne. 
Cette approche a l'avantage de s'appuyer sur des protocoles existants. La communaute 
Java EE possede notamment des projets d'adaptateurs pour les protocoles SNMP, HTTP et 
CORBA. 
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• Approche par connecteur. Contrairement aux adaptateurs, les connecteurs ont un impact sur 
l'application cliente puisqu'ils sont composes d'une partie cliente et d'une partie serveur, 
ces entites etant standardises par le biais de la JSR 160. 

Le code suivant illustre F utilisation d'un connecteur avec les API JMX au niveau du serveur 
JMX afin d'autoriser son acces : 

//Recuperation du serveur JMX 
MbeanServer server = getMBeanServer( ) ; 

//Creation de 1'URL d'acces au connecteur 
JMXServi ceURL url = new JMXServiceURKserviceUrl); 

//Creation de 1 'envi ronnement 

Map environment = createEnvi ronment( ) ; 

//Creation du connecteur serveur 
JMXConnectorServer connectorServer - 

JMXConnecto rServer Factory .newJMXConnectorServer( 

url, environment, server); 

//Demarrage du connecteur 
connectorServer. startt ) ; 

(...) 

//Arret du connecteur 
connectorServer. stop( ) ; 

Une fois la partie serveur du connecteur realisee, l'application cliente met en ceuvre un 
connecteur client, comme dans le code suivant : 

//Creation de 1'URL du connecteur a acceder 
JMXServi ceURL url = new JMXServiceURKserviceUrl); 

//Creation de 1 'envi ronnement 

Map environment = createEnvi ronment( ) ; 

//Creation du connecteur client 

JMXConnector connector = JMXConnectorFactory.connect( 

url, thi s .envi ronment ) ; 

//Recuperation d'un connecteur au serveur JMX 
MbeanServerConnection connection = 

connector. getMBeanServerConnectiont ) ; 



Les notifications JMX 



La specification JMX standardise un mecanisme robuste et complet permettant aux composants 
enregistres ou aux agents JMX d'emettre des notifications vers les applications de supervision. 
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Les mecanismes de notification s'appuient sur les deux interfaces JMX decrivant l'observa- 
tion ainsi que la facon de les associer ou les dissocier d'un MBean. 

L'interface NotificationListener du package javax. management represente un observateur 
JMX qui peut etre notifie par divers evenements. Les observateurs JMX doivent implementer 
cette interface, decrite dans le code suivant : 

public interface NotificationListener { 
void handleNotification( 

Notification notification, Object handback); 

} 

Elle definit ensuite une fonction de rappel, qui est invoquee lorsqu'un de ces MBeans 
observes emet une notification. Le second parametre de la methode handleNotifi cation 
correspond a des informations globales, specifiees au moment de l'enregistrement des 
observateurs. 

En complement de cette interface, l'interface NotificationFilter est mise a disposition afin de 
permettre un filtrage des notifications recues et traitees. Cette interface possede le code suivant : 

public interface NotificationFilter { 

boolean isNotificationEnabled(Notification notification); 

I J 

Pour finir, l'interface NotificationBroadcaster du package javax. management permet aux 
MBeans d' associer et de desassocier des observateurs par le biais de methodes de cette inter- 
face appelees par le serveur de MBeans. 

Le code suivant decrit cette interface : 

public interface NotificationBroadcaster { 

void addNotificationListener( Notification Listener 1 istener, 

NotificationFilter filter, Object handback); 
MBeanNotificationInfo[] getNotificationlnfot ) ; 
void removeNotif i cati on Li stener( 

NotificationListener listener) ; 

} 

La figure 18-2 illustre l'association et la desassociation des observateurs sur un MBean ainsi 
que leur notification. 
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Les MBeans de types simple et dynamique doivent necessairement implementer V interface 
NotificationBroadcaster pour utiliser les mecanismes de notification. La specification JMX 
fournit pour cela 1' implementation NotificationBroadcasterSupport de cette interface dans le 
package javax. management, que ces types de MBeans peuvent etendre pour beneficier directe- 
ment de ces mecanismes. 

Les MBeans de type modele fonctionnent differemment pour les notifications. L'implementa- 
tion RequiredModelMBean de Finterface Model MBean etend indirectement 
NotificationBroadcaster par le biais de l'interface Model MBeanNotificationBroadcaster. Cela 
permet a ce type de MBeans de beneficier automatiquement des mecanismes de notification. 

Enregistrement 

Une fois les MBeans prets a utiliser les mecanismes de notification et les observateurs imple- 
mentes, l'application doit les associer les uns aux autres par 1' intermediate du serveur de 
MBeans. 

Le serveur fournit les methodes addNotificationListener et removeNotificationListener 
dans son interface MBeanServer dans le but d' associer ou desassocier un observateur, dont les 
signatures sont decrites dans le code ci-dessous : 

public interface MBeanServer extends MBeanServerConnecti on { 
(...) 

void addNotificationListener(ObjectName name, 

NotificationListener 1 istener, 
NotificationFilter filter, Object handback); 

void addNotificationListenert 

ObjectName name, ObjectName listener, 
NotificationFilter filter, Object handback); 

void removeNotif i cation Listener ( 

ObjectName name, ObjectName listener); 

void removeNotif i cation Listener ( 

ObjectName name, ObjectName listener, 
NotificationFilter filter, Object handback); 

(...) 

} 

Lassociation et la desassociation peuvent etre realisees en utilisant l'instance ou le nom JMX 
de l'observateur. Dans le premier cas, l'observateur est ajoute automatiquement dans JMX. 

Les methodes precedentes permettent de specifier egalement les parametres suivants : 

• Un nitre de type NotificationFilter offrant la possibilite de filtrer les notifications envoyees 
a l'observateur. La specification JMX fournit F implementation Noti f i cati onFi 1 terSupport 
pour cette interface. 

• Un objet handback permettant de specifier des informations generates envoyees a l'observateur 
en meme temps que les notifications. 

Le code suivant illustre la fa5on d'utiliser le serveur de MBeans afin d'associer ou desassocier 
un observateur de notifications a un MBean : 
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//Recuperation du serveur utilise 
MBeanServer server = getMBeanServer( ) ; 

//Creation du MBean 

ModelMBean modelMBean = createModelMBean( ) ; 
ObjectName objectName = getObjectName( ) ; 

//Enregistrement du MBean dans le serveur 
server. regi sterMBean( model MBean .objectName) ; 

//Creation de 1 'observateur 

NotificationListener listener = createNotificationListenerO; 

//Association de 1 'observateur pour le MBean 

server . addNoti fi cation Li stener( object Name, 1 i stener ,nul 1 ,nul 1 ) ; 



Implementations de JMX 

Cette section decrit les implementations JMX les plus courantes ainsi que les consoles de 
supervision compatibles JMX. 

Implementations serveur 

Depuis la version 5.0 de Java, la machine virtuelle inclut en natif un serveur JMX, qui permet 
de superviser aussi bien ses constituants que les composants des applications. 

Pour Factiver, le parametre com. sun. management, jmxremote doit etre specifie dans la ligne de 
commande de lancement de la machine virtuelle, comme dans le code suivant : 

> java -Dcom. sun. management. jmxremote -classpath (...) (...) 

Le projet MX4J, accessible a l'adresse http://mx4j.sourceforge.net/, propose une implemen- 
tation Open Source robuste de JMX. La specification du parametre javax. mana- 
gement, builder. initial dans la ligne de commande de lancement de la machine virtuelle 
permet de l'utiliser, comme dans le code suivant : 



(...) 



//Desenregi strement du MBean dans le serveur 
server . un regi sterMBean( object Name) ; 



//Desassociation de 1 'observateur pour le MBean 
server. removeNotifi cation Li stener (object Name, 1 i stener) ; 



> java -Djavax. management. builder. initial 

=mx4j .server. MX4JMBeanServerBui 1 der -classpath (...) (...) 



Les serveurs d' applications Java EE integrent generalement leur propre implementation de 
JMX, tels WebSphere et son implementation developpee par Tivoli. 



Spring en production 

Partie V 

Clients JMX 

L'objectif de ces clients JMX est d'offrir une console de supervision afin d'interagir avec les 
MBeans aussi bien par le biais de leurs proprietes que par F invocation d' actions. 

JConsole 

Depuis sa version 5.0, Java fournit en natif une console de supervision JMX, qui peut etre 
demarree par 1' intermediate du binaire jconsole.exe sous Windows. Elle permet de se 
connecter a des processus Java locaux ou distants. 

Cette console donne acces a des informations concernant le fonctionnement de la machine 
virtuelle aussi bien que des MBeans de l'application, comme Fillustrent les figures 18-3 et 18-4. 



ring C< Management Console: 3(Mi«localhost 



Connection 


Summary Memory | Threads Classes MBeans 


VM 


Summary 


1 


Uptime: 27,906 seconds 


Process CPU time: 1,609 seconds 


Total compile time: 0,193 seconds 




Threes 




l ive Tin-path : 


Peak: 20 


Daemon threads: 14 


Total started: 20 


Memory 

Current heap size: 1 101 kbytes 


Committed memory: 2 140 kbytes 


Maximum heap size: 65 088 kbytes 




Objects pending for finalization: 0 




Garbage collector: Name ■ 'Cop/, Collections • 28, Total tone spent — 0,136 seconds 


Garbage collector: Name ■ 'MatkSwwpCompacf, Collections = 0, Total tune spent ■ 0,000 seconds 


Classes 




Current classes loaded: 1 810 


Total classes unloaded: 2 


Total classes loaded: 1 813 




Operating System 


Total physical memory: 1 039 728 kbytes 


Free physical memory: 367 016 kbytes 


Committed virtual memory: 16 224kbytes 





Figure 18-3 

Informations concernant le processus Java 



Supervision avec JMX 

Chapitre 18 



n 








Connection 






— — ™ » 1 * 1 ~ 1 — — — 1 — — — — 1 — 1 




M 












£jl Tree 

* Q ^Implementation 


Attributes Operations Hot Hic.it .oris Mo 






Name 








9 MBeanServeiD' 
» C3tonnottor 


Active 


Hue 








seiwe im< mni motalhostrmMmi »loc amost 1 0991 








Attributes 


II 






*■ C3 lava Lang 


Connectwnlds 


(aviUng.SH mg(0| 






°- n iav-3 util logging 


MBeanServerf orwaider 
























<i II I IH 











Figure 18-4 

Informations concernant les MBeans enregistres dans le serveur JMX 



MC4J 

Le projet MC4J, accessible a l'adresse http://mc4j.sourceforge.net/, fournit une implementation 
d'une console de supervision compatible JMX. Elle permet de se connecter a differents 
serveurs JMX par le biais de connecteurs dedies. 

La figure 18-5 illustre le fonctionnement de cet outil. 



Figure 18-5 
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En resume 

La specification JMX fournit un cadre normalise, robuste et eprouve afin de rendre des appli- 
cations Java/Java EE supervisables. Elle decrit les differentes ressources supervisables, les 
entites qui les gerent et la facon de les acceder depuis des applications externes. 

De nombreux projets Open Source fournissent aussi bien des implementations de serveur 
JMX que des consoles de supervision compatibles avec cette technologie. L'enjeu consiste a 
adresser de maniere optimale 1' integration de cette technologie au sein de ces applications. 

La section suivante detaille le support de JMX par Spring visant a integrer cette technologie 
dans les applications par declaration. 

JMX avec Spring 

Spring facilite l'enregistrement et la gestion de Beans simples dans un serveur JMX. Le 
framework construit automatiquement les MBeans correspondant en specifiant les proprietes 
et methodes accessibles par les applications de supervision. 

Lobjectif du support JMX de Spring est d'integrer par declaration cette technologie au sein 
d' applications Java/Java EE utilisant ce framework. Avec Spring, F instrumentation des 
composants pour la supervision ne se fait plus au sein du code, mais au moment de 1' assem- 
blage de ces composants par declaration. 

Spring offre egalement la possibilite de specifier des metadonnees par le biais notamment des 
annotations, qui permettent d' exporter aisement des informations dans JMX. 

Fonctionnalites du support JMX par Spring 

Grace a de nombreuses fonctionnalites dediees, le support JMX de Spring est tres complet. 

Avant de detailler ces fonctionnalites dans les sections suivantes, le tableau 18-2 en donne un 
bref recapitulatif. 



Tableau 18-2. Support JMX de Spring 



Fonctionnalite 


Description 


Exportation des MBeans 


Permet d'enregistrer un composant ou un MBean dans un serveur JMX par declaration. 


Determination des informations 
exposees dans JMX 


La fonctionnalite precedente doit determiner les informations qui seront utilisees et rendues 
visibles par le serveur JMX. Plusieurs strategies sont fournies afin de determiner les meta- 
donnees du composant pour JMX (reflexion, annotations, interface, etc.). 


Determination du serveur JMX 
utilise 


L'exportation offre plusieurs strategies (implicites ou explicites) afin de determiner le serveur 
JMX a utiliser. 


Gestion des noms des MBeans 


Lors de l'exportation des MBeans, un nom doit etre determine afin de les identifier dans le 
serveur JMX. 


Configuration et utilisation 
des connecteurs JSR 160 


Le support offre des facilites afin de mettre en ceuvre des connecteurs JSR 160 permettant 
de rendre accessible un serveur JMX ou d'y acceder. 


Configuration et utilisation des 
notifications 


Le support offre des mecanismes afin d'associer par declaration des observateurs a des 
MBeans et de declencher des evenements. 
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Exportation de MBeans 

Spring fournit de nombreuses fonctionnalites permettant d'enregistrer des Beans en tant que 
MBeans dans un serveur JMX. 

Le framework offre egalement diverses approches dans le but de controler les proprietes et 
methodes exposees qui seront visibles et utilisables par les applications de supervision. 

M Bean Ex porter 

La classe centrale du support JMX, MBeanExporter, localisee dans le package 
org. springf ramework. jmx. export, permet de convertir un composant en un MBean suivant 
des criteres specifies par declaration et de l'enregistrer automatiquement dans le serveur JMX. 

Le code suivant donne un exemple simple d' exportation d'un Bean dans JMX avec l'identifiant 
bean:name=testBeanl : 

<beans> 

<bean id="exporter" 

cl a ss=" org. springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBeanl" val ue-ref="testBean"/> 
</map> 
</property> 
</bean> 

<bean id="testBean" cl ass="tudu. jmx.JmxTestBean"> 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 

</beans> 

Des observateurs peuvent etre configures sur cette classe afin d'etre avertis de l'enregistre- 
ment ou du desenregistrement d'un MBean. Remarquons que ce mecanisme est propre a 
Spring, et non a JMX. 

Ce type d'observateur doit implementer l'interface MBeanExporterListener suivante : 

public interface MBeanExporterListener { 

void mbeanRegi stered(ObjectName objectName); 
void mbeanUnregi stered(ObjectName objectName); 

} 

L'enregistrement des observateurs de ce type s'effectue grace a la propriete listeners de la 
classe MBeanExporter, cette derniere correspondant a un tableau d'ecouteurs de type 
MBean Exporter Li stener. 

Le code ci-dessous donne un exemple de configuration simple specifiant des ecouteurs : 

<beans> 
<bean id="exporter" 
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cl ass="org .spri ngframework. jmx. export .MBean Exporter "> 
<property name="l i steners"> 
<list> 

<bean class="MonListenerl"/> 
<bean class="MonListener2"/> 
</list> 
</property> 
</bean> 
</beans> 

La classe MBeanExporter offre egalement la possibility de specifier le comportement a avoir 
lors de l'enregistrement d'un MBean lorsqu'un element de ce type est deja enregistre avec le 
meme nom. Par defaut, cette classe leve une exception de type 
InstanceAlreadyExistsException, mais cet aspect peut etre configure en se fondant sur la 
propriete regi strati onBehaviorName. 

Le tableau 18-3 recapitule les differentes valeurs possibles pour cette propriete en fonction du 
comportement souhaite. 



Tableau 18-3. Valeurs possibles pour la propriete registrationBehaviorName 



Valeur 






Comportement correspondant 


REGISTRATION. 


_FAIL_0N 


.EXISTING 


Correspond a la strategie par defaut de I'exportateur. Si un MBean est present 
dans le serveur sous le meme nom, une exception de type InstanceAl rea- 
dyExi sts Excepti on est levee. Dans ce cas, aucune modification n'est apportee 
au MBean existant. 


REGISTRATION. 


.IGNORE. 


EXISTING 


Permet d'ignorer l'enregistrement d'un MBean si un MBean est present dans le 
serveur sous le memememe nom. Comme precedemment, aucune modification 
n'est apportee au MBean present. 


REGISTRATION. 


.REPLACE 


.EXISTING 


Permet de remplacer I'ancien MBean par le nouveau pour un nom donne. 



Le code suivant illustre la configuration de la deuxieme strategie par 1' intermediate de la 
propriete registrationBehaviorName (Q) afin de ne pas enregistrer un MBean lorsqu'une 
entite similaire est presente dans JMX sous le meme nom : 

<beans> 



<bean id="exporter" 

cl a ss=" org .spri ngf ramework. jmx. export .MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="regi strati onBehavi or Name 

val ue="REGISTRATION_IGNORE_EXISTING"/> 

</bean> 



<bean id="testBean" class= 



"> 
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</bean> 
</beans> 

Selection et detection du serveur JMX 

II est possible de laisser Spring detecter automatiquement le serveur JMX present. Cette 
approche est ideale dans le cas ou un serveur JMX est fourni par F infrastructure technique 
(Java 5+ ou serveurs d' applications, par exemple). II est parfois preferable de specifier le 
serveur JMX souhaite, notamment lorsque l'application utilise sa propre instance de serveur 
JMX. 

L' approche par detection automatique s'appuie implicitement sur les API de JMX, en particu- 
lier la methode findMBeanServer de l'interface MBeanServerFactory et la methode 
getPl atf ormMBeanServer de la classe ManagementFactory. Pour sa part, l'approche par selection 
de serveur consiste, comme le montre le code suivant, a configurer le serveur en tant que Bean 
(©) P u i s ^ l injecter explicitement dans le Bean d'exportation (Q) : 

<beans> 

<bean id="mbeanServer"<— Q 
cl ass="org. spri ngf ramework. jmx. support . MBeanServerFactory Bean" /> 

<bean id="exporter" 

cl a ss=" org. spri ngf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean" val ue- ref="testBean"/> 
</map> 
</property> 

<property name="server" ref="mbeanServer"/><— Q 
</bean> 

<bean id="testBean" class="..."> 
</bean> 
</beans> 



Controle des informations exportees 

Nous allons maintenant detailler les diverses approches permettant de controler les informations 
exportees et accessibles par JMX. 

La fonctionnalite de controle des informations exportees permet de parameter la construction 
des MBeans par rapport aux Beans de l'application. Sa configuration a Favantage de pouvoir 
ete specifiee au moment de 1' assemblage des composants de l'application et n'a done aucun 
impact sur l'application existante. 
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L interface MBeanlnfoAssembler 

L'interface MBeanlnfoAssembler permet de definir l'interface de supervision specifiant les 
informations a exposer pour chaque composant. La classe MBeanExporter delegue ces traite- 
ments a une implementation de cette interface. 

La classe SimpleReflectiveMBeanlnfoAssembler est utilisee par defaut, mais il est possible 
d'en specifier une autre configuree en tant que Bean (Q) et injectee par le biais de la propriete 
assembl er (Q), comme dans le code suivant : 

<beans> 

<bean id="exporter" 

cl a ss=" org. springframework.jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBeanl"> 

<ref local-"testBean"/> 
</entry> 
</map> 
</property> 

<property name="assembl er" ref="assembl er"/><— Q 
</bean> 

<bean id="assembler" cl ass=" . . . "><— Q 
</bean> 
</beans> 

Les implementations de cette interface ont la responsabilite de creer les informations concer- 
nant un MBean de type modele a partir d'une instance quelconque de Bean, comme dans 
Fexemple suivant : 

public interface MBeanlnfoAssembler { 

ModelMBeanlnfo getMBeanInfo(Object managedBean, 

String beanKey) throws JMException; 

} 

Les implementations du controle de ces informations par le support JMX de Spring selon la 
strategie desiree sont recapitulees au tableau 18-4. 



Tableau 18-4. Implementations du controle des informations 



Implementation 


Description 


Simpl eRef 1 ecti veMBeanlnfoAssembl er 


Permet de determiner par introspection les informations a rendre visibles 
dans JMX. 


MetadataMBeanlnfoAssembl er 


Permet de configurer les strategies de recuperation des metadonnees 
des composants relatives a JMX. 


MethodNameBasedMBeanlnfoAssembl er 


Permet de specifier les noms des methodes utilisables afin de deter- 
miner les informations a rendre visibles dans JMX. 
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Tableau 18-4. Implementations du controle des informations (suite) 



Implementation 


Description 


MethodExcl usionMBeanlnfoAssembl er 


Permet de configurer les noms des methodes a ne pas utiliser dans le 
but de determiner les informations a rendre visibles dans JMX. 


InterfaceBasedMBeanlnfoAssembl er 


Permet de specifier les noms des methodes par le biais d'interfaces 
afin de determiner les informations a rendre visibles dans JMX. 



Les sections qui suivent detaillent la facon d'utiliser ces differentes implementations. 



Lapproche par annotations 

Cette approche s'appuie sur les annotations afin de specifier les divers attributs et methodes 
accessibles par JMX et ne peut done etre utilisee qu'avec Java 5+. Le support utilise les infor- 
mations contenues dans ces annotations afin de creer le MBean associe. 

Le tableau 18-5 recapitule les differentes annotations fournies par le support JMX de Spring. 



Tableau 18-5. Annotations fournies par le support JMX de Spring 



Annotation 


Description 


ManagedResource 


Permet d'exposer une classe ou interface avec JMX et de specifier ses proprietes associees. 


ManagedOperation 


Permet d'exposer une operation avec JMX et de specifier ses proprietes associees. 


ManagedAttribute 


Permet d'exposer un attribut avec JMX et de specifier ses proprietes associees. 


ManagedOperati on Parameter 


Permet de definir les proprietes concernant les parametres des operations avec JMX. 



Le tableau 18-6 fournit les proprietes de ces annotations. 



Tableau 18-6. Proprietes des annotations 



Propriete 


Annotation impactee 


Description 


objectName 


ManagedResource 


Definit I'ObjectName de la ressource. 


description 


ManagedResource. ManagedOperation, Fournit une description de la ressource. 
ManagedAttribute, ManagedOperati onParameter 


currencyTimeLimit 


ManagedResource, ManagedAttribute 


Definit la valeur de la propriete currencyTimeLimit. 


def aul tVal ue 


ManagedAttribute 


Definit la valeur de la propriete def aul tVal ue. 


log 


ManagedResource 


Definit la valeur de la propriete 1 og. 


1 ogFi 1 e 


ManagedResource 


Definit la valeur de la propriete 1 ogFi 1 e. 


persistPol i cy 


ManagedResource 


Definit la valeur de la propriete persi stPol icy. 


persistPeriod 


ManagedResource 


Definit la valeur de la propriete persi stPeriod. 


persistLocation 


ManagedResource 


Definit la valeur de la propriete persi stLocati on. 


persistName 


ManagedResource 


Definit la valeur de la propriete persi stName. 


name 


ManagedOperati onParameter 


Specifie le nom d'affichage d'un parametre d'une ope- 
ration. 


index 


ManagedOperati onParameter 


Specifie I'index d'un parametre d'une operation. 
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La configuration de cette approche se realise en specifiant 1' implementation 
MetadataMBeanlnfoAssembler pour 1' interface MBeanlnfoExporter. Cette implementation 
s'appuie sur les metadonnees definies dans la classe du Bean. Puisque plusieurs types de 
metadonnees peuvent etre utilises avec cette approche, une instance de la classe 
AnnotationsAttributeSource doit etre specifiee pour F implementation MetadataM- 
BeanlnfoAssembler en se fondant sur sa propriete assembler. 

L' approche par annotations peut etre configured finement afin de specifier les attributs et 
methodes a rendre visibles dans JMX ainsi que leurs proprietes. Elle offre egalement la possi- 
bilite d'alleger la configuration JMX dans Spring puisque les Beans utilisant les annotations 
JMX de Spring peuvent etre detectes et enregistres automatiquement dans le serveur. 

Le code ci-dessous decrit la maniere de mettre en ceuvre cette strategie avec les classes 
AnnotationsAttributeSource (Q) et MetadataMBeanlnfoAssembler (©), une instance de cette 
derniere etant ensuite injectee dans l'exportateur (Q) : 

<beans> 

<bean id="exporter" 

cl ass="org .spri ngf ramework. jmx. export .MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBeanl" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="assembl er" ref="assembl er"/><— O 
</bean> 

<bean id="testBean" cl ass="tudu. jmx. JmxTestBean"> 

<property name="name" val ue-"TEST"/> 

<property name="age" val ue-"100"/> 
</bean> 

<bean id="attributeSource" cl ass="org.springf ramework. jmx<—@ 
.export .metadata . AnnotationsAttri buteSource"/> 

<bean id="assembl er" class="org.springframework.jmx<— Q 

.assembl er .MetadataMBeanlnfoAssembl er"> 
<property name="attributeSource" ref="attributeSource"/> 
</bean> 

</beans> 

L'approche par autodetection 

Dans cette approche, le support JMX de Spring recherche automatiquement les Beans qui 
possedent des informations utilisables pour construire des MBeans JMX. Elle necessite 
Futilisation d'une entite d' assemblage implementant Finterface AutodetectCapableMBeanlnfo. 
La seule implementation de MBeanlnfoAssembler respectant ce critere est la classe 
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MetadataMBeanlnfoAssembler decrite precedemment, qui pemiet d'utiliser notamment des 
annotations en tant que metadonnees. 

Avec cette approche, Spring prend comme objectName Fidentifiant du Bean lors de son enre- 
gistrement en tant que MBean. 

Ann d'activer cette approche, la valeur de la propriete autodetect de la classe MBeanExporter 
doit etre positionnee a true (Q), comme dans le code suivant : 

<beans> 
<bean id="exporter" 

cl a ss=" org. springf ramework. jmx. export. MBean Exporter "> 
<property name="assembl er" ref="assembl er"/> 
<property name="autodetect" val ue="true"/><— Q 
</bean> 



<bean id="bean:name=testBeanl" 

class="tudu. jmx. JmxTest Bean" > 
<property name="name" val ue="TEST"/> 
<property name="age" val ue="100"/> 

</bean> 



<bean id="attributeSource" class="org.springframework. jmx 

.export .metadata . Annotations Attri buteSource"/> 



<bean id="assembler" class="org.springframework. jmx 

.export . a ssembl er .MetadataMBeanlnfoAssembl er"> 
<property name="attributeSource" ref-"attributeSource"/> 
</bean> 
</beans> 

Remarquons que la configuration de la classe MBeanExporter est beaucoup plus concise et 
qu'il n'est plus necessaire de specifier les MBeans a enregistrer au niveau de la classe prece- 
dente. 

II est a noter que Spring offre dans ce contexte une interessante sous-classe de la classe 
MBeanExporter, la classe AnnotationMBeanExporter, afin de configurer automatiquement une 
approche fondee sur les annotations Java 5. Cette approche peut etre configuree tres simple - 
ment en se fondant sur l'espace de nommage context de Spring, comme dans le code suivant : 

<beans xmlns=" http://www.spr ingframework.org/schema /beans" 

xml ns : con text=" http : //www. spri ngf ramework. org/ schema /context " 
(...)> 



<con text :mbean- export /> 



</beans> 

Une instance de serveur JMX peut etre egalement specifiee a l'aide de l'attribut server de la 
balise mbean-export. 
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Lapproche par interfaces 

Les informations a exposer dans JMX peuvent etre specifiees par F intermediate d'interfaces. 
Comme dans le code suivant, cette methode s'appuie sur F implementation 
InterfaceBasedMBeanlnfoAssembler (Q) de Finterface MBeanlnfoAssembl er, qui permet de 
configurer les interfaces prises en compte par Fintermediaire de la propriete 
managedlnterf aces (Q) : 

<beans> 

<bean id="exporter" 

cl ass=" org. springframework. jmx. export. MBean Exporter") 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean5"> 

<ref local-"testBean"/> 
</entry> 
</map> 
</property> 

<property name="assembl er"> 

<bean cl ass="org.springframework<— Q 

.jmx. export .assembl er. InterfaceBasedMBeanlnfoAssembl er"> 
<property name="managedlnterf aces"><— Q 

<val ue>tudu. jmx. UmxTestBean</val ue> 
</property> 
</bean> 
</property> 
</bean> 

<bean id="testBean" cl ass="tudu. jmx. JmxTestBean"> 

<property name="name" val ue-"TEST"/> 

<property name="age" val ue-"100"/> 
</bean> 
</beans> 

Lapproche par noms de methodes 

Les methodes et attributs a exposer dans JMX peuvent etre selectionnes en se fondant sur leur 
nom ainsi que sur ceux de leurs accesseurs et mutateurs, informations utilisees lors de la crea- 
tion des MBeans associes. 

Dans l'exemple ci-dessous, une instance de 1' implementation MethodNameBasedM- 
BeanlnfoAssembler est specifiee (0) pour la propriete assembler de la classe 
MBeanExporter ; la propriete managedMethods de cette implementation permet de specifier 
les noms de methodes (Q) : 

<bean id="exporter" 

cl ass-"org. springframework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean5" ref="testBean"/> 
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</entry> 
</map> 
</property> 

<property name="assembl er"> 
<bean cl ass="org. springf ramework. jmx. export*— Q 

. assembl er . MethodNameBasedMBeanlnfoAssembl er"> 
<property name="managedMethods"><— Q 

<value>add,myOperation,getName,setName,getAge</val ue> 
</property> 
</bean> 
</property> 
</bean> 



Gestion des noms des M Beans 

Le support de Spring permet de specifier les noms des MBeans de trois manieres differentes. 
Les deux premieres consistent a les declarer explicitement lors de la configuration de la classe 
MBeanExporter de Spring tandis que la troisieme s'appuie sur des informations contenues dans 
les metadonnees des composants a exposer dans JMX. 

La premiere approche permet de definir les noms des MBeans au moment de la configuration 
de la classe MBeanExporter. Cette approche n'a aucun impact sur les Beans et ne necessite 
done aucune modification de leur code source. Les Beans ne sont pas done dans l'obligation 
de suivre les conventions de codage imposees par certains types de MBeans. 

Les Beans a exporter sont specifies par 1' intermediate de la propriete beans de l'exportateur, 
propriete de type Map. Les cles de cette table de hachage correspondent aux noms JMX, et les 
valeurs font reference aux instances des Beans a exporter. 

Le code suivant donne un exemple de mise en ceuvre de cette fonctionnalite par l'interme- 
diaire de la propriete beans (Q) : 

<beans> 

<bean id="exporter" 

cl a ss=" org. springf ramework. jmx. export. MBeanExporter "> 
<property name="beans"><— Q 
<map> 

<entry key="bean:name=testBeanl" val ue-ref="testBean"/> 
</map> 
</property> 
</bean> 

<bean id="testBean" cl ass="tudu. jmx. JmxTestBean"> 

<property name="name" val ue="TEST"/> 

<property name="age" val ue="100"/> 
</bean> 
</beans> 

La deuxieme approche consiste a externaliser de l'exportateur la definition des noms des 
MBeans JMX. Dans ce cas, la cle de la table de hachage de la propriete beans de la classe 
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MBeanExporter correspond non plus a un ObjectName, mais a une reference qui est resolue par 
le biais d'une instance de l'interface ObjectNamingStrategy. L' implementation KeyNaming- 
Strategy de cette interface met alors en ceuvre une resolution en utilisant un fichier de proprietes 
ou une table de hachage. 

Le code suivant donne un exemple d'utilisation de la classe KeyNamingStrategy (Q), 
Finstance de cette derniere etant injectee par F intermediate de la propriete namingStrategy 
(O) ^ la classe MBeanExporter : 

<beans> 

<bean id="exporter" 

cl a ss=" org. springframework. jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="namingStrategy" ref="namingStrategy"/><— Q 
</bean> 

<bean id="testBean" cl ass="org . springframework. jmx. JmxTest Bean" > 

<property name="name" val ue-"TEST"/> 

<property name="age" val ue-"100"/> 
</bean> 

<bean id-"nami ngStrategy" class="org.springframework<— Q 

. jmx. export. naming. Key NamingStrategy "> 
<property name="mappings"> 
<props> 

<prop key-" test Bean " >bea n :name=testBean</prop> 
</props> 
</property> 

<property name="mapping Locations'^ 
<val ue>names .properties </val ue> 
</property> 
</bean> 
</beans> 

Par exemple, le code du fichier de proprietes names.properties est de la forme : 

testBeanl=bean:name=testBeanl 

Dans la troisieme approche, le nom du MBean est specifie dans la propriete objectName de 
Fannotation ManagedResource (Q) : 

@ManagedResource(objectName="bean :name=testBeanl" )<— Q 
public class JmxTestBean { 
(...) 

} 

La section precedente relative aux annotations fournit de plus amples details sur leur utili- 
sation. 
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Les connecteurs JSR 160 

Les connecteurs adressent le niveau services distribues arm de permettre Faeces a un serveur 
JMX distant. 

La specification JMX distingue deux types de connecteurs. Le premier est mis en ceuvre 
conjointement avec le serveur JMX de maniere a le rendre accessible. Le second doit pour sa 
part etre utilise dans 1' application desirant se connecter au serveur distant. 

Les connecteurs serveur 

Dans la plupart des cas, ces connecteurs sont deja presents dans 1' infrastructure JMX fournie. 
Concernant les serveurs d' applications, ces connecteurs sont automatiquement associes et 
demarres pour les composants du niveau agent de JMX. L utilisation d'un serveur JMX dedie 
favorise la mise en pratique de connecteurs serveur dans certaines applications. 

Spring supporte cette fonctionnalite par F intermediate de la classe ConnectorServer- 
FactoryBean, localisee dans le package org. springf ramework. jmx. support. Cette entite 
offre la propriete objectName afin de s'enregistrer automatiquement dans le serveur JMX. 
Le connecteur peut egalement etre execute dans un nouveau thread grace a la propriete 
threaded. 

Le code suivant donne un exemple de configuration d'un connecteur fonde sur le protocole 
RMI (Q), ce qui necessite la mise en ceuvre d'un serveur RMI dans Spring (Q) : 

(...) 

<bean id="registry" class="org.springframework.<— Q 

remoting. rmi . Rmi Regi stryFactoryBean"> 
<property name="port" val ue="1099"/> 
</bean> 

<bean id="serverConnector" class="org.springframework.<— Q 

jmx. support .ConnectorServer Factory Bean" > 
<property name="server" ref="mbeanServer" /> 
<property name="objectName" value="connector:name=rmi "/> 
<property name="serviceUrl " 

val ue=" service: jmx: rmi : //l ocal host/jndi / 

rmi : //l ocal host : 1099/my connector "/> 
<property name="threaded" val ue-"true"/> 
</bean> 

Les connecteurs client 

Ce type de connecteur permet Faeces a un serveur JMX distant associe a un connecteur 
serveur depuis une application cliente. Spring fournit alors la classe MBeanServer- 
ConnectionFactoryBean dans le meme package que precedemment avec une unique propriete 
obligatoire serviceUrl, qui permet de definir l'adresse d'acces au connecteur, tout en indi- 
quant le protocole utilise. 
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Le code suivant en donne un exemple de mise en ceuvre permettant d'utiliser le connecteur 
serveur decrit a la section precedente : 

<bean id="cl ientConnector" class-"org.springframework. 

jmx. support .MBeanServe rConnect ion Factory Bean" > 
<property name="servi ceUrl " 

val ue=" service: jmx: rmi : //l ocal host/jndi / 

rmi : //l ocal host : 1099/my connector "/> 

</bean> 



Les notifications 

Spring offre un support des notifications de JMX arm de pouvoir aussi bien enregistrer des 
observateurs sur des notifications existantes que de publier des notifications, ce support 
s'appuyant sur la classe MBeanExporter du package org. springframework. jmx. export. 

Observateurs de notifications 

Comme le montre le code suivant, la classe MBeanExporter foumit une propriete 
notificationListenerMappings de type Map (Q) afin de configurer differents observateurs de 
ce type tout en les associant a un ou plusieurs MBeans : 

<bean id="exporter" 

cl ass=" org. springframework. jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key-"testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="noti fi cation Li stenerMappings"><— © 
<map> 

<entry key="*" value-ref="jmxNotificationListener"/> 
</map> 
</property> 
</bean> 

<bean id="jmxNotif icationListener" 

cl ass="tudu. jmx. MyJmxNotif i cation Listener "/> 

Les valeurs utilisees pour les cles des elements de la table de hachage peuvent correspondre 
aux differents types de valeurs recapitulees au tableau 18-7. 



Tableau 18-7. Types de valeurs utilisables pour les cles de la table de hachage 



Type de valeur 


Description 


Nom de MBean (ObjectName) 


Permet de specifier que I'observateur enregistre porte sur le MBean associe au nom JMX spe- 
cific. 


Identifiant de bean Spring 


Permet de specifier que I'observateur enregistre porte sur le MBean configure dans Spring avec 
I'identifiant et exporte dans JMX. 


Valeur « * » 


Permet de specifier que I'observateur enregistre porte sur tous les MBeans contenus dans JMX. 
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La classe MBeanExporter peut etre mise en ceuvre exclusivement pour deflnir des observateurs 
sur des MBeans precedemment enregistres. 

Une utilisation courante de cette propriete correspond a la configuration d' observateurs pour 
la classe MBeanServerDel egate, qui permet de recevoir notamment les evenements correspon- 
dant aux enregistrements ou desenregistrements de MBeans, comme dans Fexemple suivant : 

<bean id-"exporter" 

cl as s=" org. springf ramework. jmx. export. MBeanExporter "> 
<property name="noti fi cation Li stenerMappi ngs"> 
<map> 

<entry key=" JMImpl ementation: type=MbeanServerDel egate" 
val ue-ref-" jmxNoti fi cation Li stener"/> 

</map> 
</property> 
</bean> 

<bean id=" jmxNotif i cation Li stener" 

cl ass="tudu. jmx. MyJmxNotifi cation Li stener "/> 

Le support JMX offre une autre approche de configuration des observateurs de notification. Cette 
approche se fonde sur la propriete notificationListeners de type List et la classe 
Not if i cation Li stenerBean de Spring, presente dans le package org. springf ramework. jmx. export. 

Le nom des MBeans impactes par l'observateur est desormais specifie au niveau des instances 
des classes Notification Li stenerBean configurees (Q) par l'intermediaire de la propriete 
mappedObjectNames (Q) : 

<bean id-"exporter" 

cl as s=" org. springf ramework. jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 

<entry key="bean:name=testBean" val ue-ref="testBean"/> 
</map> 
</property> 

<property name="noti fi cation Li stener "> 
<list> 

<bean cl a ss=" org. springf ramework<— Q 

. jmx. export . Not i fi cation Li stener Bean "> 
<constructor-arg ref=" jmxNotif i cationListener"/> 
<property name="ma ppedObject Names "><—Q 
<list> 

<val ue>bean :name=testBean</val ue> 
</list> 
</property> 
</bean> 
</list> 
</property> 
</bean> 



<bean i d=" jmxNoti f i cati on Li stener" 

cl as s=" MyJmxNotifi cati onListener"/> 
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Publication de notifications 

II est possible de publier les notifications JMX grace a l'interface Noti f i cati onPubl i sher dans 
le package org. springframework. jmx. export. notification, comme dans le code suivant : 

public interface Noti fi cati onPubli sher { 

void sendNotifi cati on (Notification notification); 

} 

En complement de cette derniere, l'interface Noti fi cati onPublisherAware permet Finjection 
automatique d'une instance de type Noti fi cati onPubli sher par le conteneur Spring dans un 
Bean exporte en tant que MBean par Spring. Cette instance peut ensuite etre directement utili- 
see par le Bean afin de publier une notification JMX. 

Le code suivant illustre la mise en ceuvre dans un Bean de l'interface Noti fi cati on- 
PublisherAware (Q) et l'utilisation de la classe NotificationPubl isher (Q) afin d'envoyer 
une notification : 

public class TestBean implements NotificationPubl isherAware {<— O 
private NotificationPublisher notificationPublisher; 
(...) 

public void unTraitement( ) { 

this . noti fi cati onPubl i sher. sendNotifi cati on (<—Q 

new NotificationC'Un message", this, 0)); 

} 

public void setNotificationPublisher(<— Q 

NotificationPublisher notificationPublisher) { 
thi s. noti fi cati onPubl isher = notificationPublisher; 

} 

} 

Cette interface ne peut pas etre utilisee dans un Bean Spring quelconque. Dans ce cas, les API 
JMX classiques peuvent neanmoins etre mises en ceuvre afin de publier des notifications. 

En resume 

Le support JMX de Spring offre un cadre flexible pour utiliser et configurer les elements des 
differents niveaux de cette technologie. Au moment de 1' assemblage des composants, le deve- 
loppeur choisit la facon dont sont enregistres les Beans dans le serveur JMX. Le support peut 
utiliser aussi bien un serveur dedie a 1' application qu'un serveur fourni par l'environnement 
d' execution, tel qu'un serveur d' applications. La facon d'acceder au serveur JMX peut egalement 
etre configured lors de 1' assemblage de 1' application. 

Les atouts de ce support consistent en la simplification de l'utilisation de JMX et dans le fait 
que le support JMX Spring peut etre utilise simplement et de maniere similaire, aussi bien 
dans des applications Java EE que dans des applications Java autonomes. 
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Mise en oeuvre du support JMX de Spring dansTudu Lists 

L' application Tudu Lists illustre de quelle facon mettre en oeuvre le support JMX de Spring 
afin d'utiliser les outils JMX d' Hibernate et ainsi de recuperer des informations concernant les 
appels aux services de F application. 

Nous separerons la configuration des elements relatifs a JMX dans le fichier de Spring jmx- 
context.xml, localise dans le repertoire WEB-INF et utilise par le contexte de F application 
Web. 

Pour la configuration du serveur JMX, nous choisissons d'embarquer dans notre application 
notre propre serveur JMX, de facon a demontrer la facilite de mise en oeuvre d'un serveur 
JMX, et ce quel que soit le type d' application Java/Java EE fonde sur Spring concerne. Nous 
utilisons F implementation MX4J de JMX. 

Pour determiner F implementation JMX utilisee, la propriete javax. manage- 
ment, builder, initial precedemment decrite doit etre specifiee dans la ligne de commande du 
serveur avec la valeur mx4j .server. MX4JMBeanServerBuilder. Les bibliotheques JMX et MX4J 
suivantes doivent en outre etre ajoutees dans le classpath : jmxremote_optional . jar, 
jmxremote. jar, jmxri .jar et mx4j .jar. 

Le code suivant illustre la configuration du serveur JMX dans le fichier jmx-context.xml du 
repertoire WEB-INF : 

I <bean id="mbeanServer" 

cl ass="org. spri ngf ramework. jmx. support .MBeanServer Factory Bean" /> 

Pour rendre ce serveur accessible depuis des consoles de supervision telles que MC4J, notre 
choix se porte sur la configuration d'un connecteur JMX fonde sur le protocole RMI. Ce choix 
impose la mise en oeuvre d'un serveur RMI au coeur de notre application en s'appuyant sur 
Spring, comme dans le code suivant : 

<bean id=" registry" 

cl as s=" org. spri ngf ramework. remoting. rmi . Rmi Regi s try Factory Bean "> 
<property name="port" val ue="1099"/> 
</bean> 

<bean id="serverConnector" class="org.springframework. jmx 

. support .ConnectorServe r Factory Bean" > 
<property name="server" ref="mbeanServer" /> 
<property name="objectName" value="connector:name=rmi "/> 
<property name-"serviceUrl " 

val ue=" service: jmx: rmi : //local host * 

/ j ndi /rmi : //local host: 1099/tudu"/> 
<property name="threaded" val ue-"true"/> 
</bean> 

Dans le code ci-dessus, le serveur JMX est disponible et accessible depuis un client JMX par 
le biais du protocole RMI, a Fadresse service:jmx:rmi : //I ocal host/jndi /rmi :// 
local host:1099/tudu. Le connecteur JMX est execute dans un thread dedie. 
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Nous configurons desormais Faeces au serveur dans la console MC4J. Nous commencons par 
creer une nouvelle connexion a un serveur, puis selectionnons un type de connexion fonde sur 
JSR 160. L'utilisation de la classe RegistryContextFactory du package 
com. sun. jndi .rmi .registry pour cette connexion est necessaire, avec en parametre Fadresse 
RMI precedemment configuree. 

La figure 18-6 illustre la fenetre de configuration de MC4J. 
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Nous pouvons maintenant mettre en ceuvre Fadaptateur fourni par MX4J pour le protocole 
HTTP grace a la classe HttpAdapter localisee dans le package mx4j .tool s. adaptor, http. Cette 
derniere se parametre en tant que Bean dans le contexte de Spring. Comme la classe prece- 
dente correspond a un MBean, elle doit etre enregistree dans un serveur JMX pour fonctionner 
correctement. 

Le code suivant montre que le support de Spring peut etre utilise afin de configurer Fadaptateur 
en tant que Bean (Q) et Fexporter dans JMX (Q) : 

<bean id="httpAdaptor" 

cl ass-"mx4j . tools. adaptor. http. HttpAdaptor"><— © 

<property name="host" val ue="l ocal host"/> 

<property name="port" val ue-"7777"/> 
</bean> 

<bean id="exporter" 

cl ass="org.springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key="tudu:service=httpAdaptor"<— Q 
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val ue-ref="httpAdaptor" /> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

Le serveur Web associe a Fadaptateur n'est pas demarre lors de son enregistrement. Pour le 
lancer et Farreter, il convient d'executer les operations start et stop par F intermediate de 
JMX . 

Nous pouvons maintenant configurer et implementer les divers elements relatifs a la supervi- 
sion. Dans notre application, les noms des differents MBeans exposes dans JMX sont prefixes 
par convention par tudu:service=. 

Utilisation d'Hibernate 

Dans un premier temps, nous utilisons le MBean JMX fourni par le framework Hibernate 
pour la supervision. Ce MBean permet d'obtenir des informations sur 1' utilisation des 
ressources JDBC, la gestion des entites, F execution des requetes ainsi que les caches. Les 
statistiques Hibernate sont obtenues a partir de la Sessi onFactory. 

Tudu Lists utilisant Hibernate via JPA, il faut parameter les proprietes Hibernate pour exposer la 
SessionFactory dans l'arbre JNDI et effectuer un lookup dans le contexte Spring. 

Comme le montre le code suivant, nous mettons en ceuvre ce MBean par le biais de la classe 
StatisticsService du package org. hibernate. jmx en tant que Bean dans Spring (Q) et 
l'enregistrons dans JMX (Qi) : 

<bean name="hibernateStatistics"<— Q 

cl ass-" org. hibernate. jmx. Statist icsService"> 
<property name="sessionFactory" ref="sessionFactory"/> 
</bean> 

<bean id="exporter" 

class="org.springf ramework. jmx. export. MBean Exporter "> 
<property name="beans"> 
<map> 

<entry key-"tudu:servi ce=hibernateStati sti cs"<— Q 

val ue-ref="hibernateStatisti cs" /> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

Tudu Lists utilise le support de la classe MBeanExporter de Spring decrite precedemment arm 
de rendre le MBean d'identifiant hi bernateStati sties disponible dans JMX avec le nom 
tudu: service: hi bernateStati sties. 
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Le service todoListsManager 

Nous cherchons maintenant a instaurer un mecanisme fonde sur JMX afin d' identifier les 
appels au service todoListsManager dans Spring. 

Dans cette optique, nous implementons un intercepteur AOP qui incremente un compteur a 
chaque appel des methodes du service. Nous exposons ensuite cette entite dans JMX afin 
d'acceder aux valeurs du compteur et eventuellement de le reinitialises 

L' intercepteur est implemente a Faide du support d' AspectJ de Spring par le biais de la classe 
TodoLi stsManagerlnterceptor localisee dans le package tudu. service. impl : 

public class TodoListsManagerlnterceptor { 
private volatile long numberOfCal 1-0; 

public Object invoke( 

ProceedingJoinPoint invocation) throws Throwable { 
numberOfCall++; 
return invocation. proceed( ) ; 

} 

public long getNumberOfCal 1 ( ) { 
return numberOfCal 1 ; 

} 

publ ic void reset( ) { 
numberOfCall-0; 

} 

} 

Le code suivant montre comment la configuration de l'intercepteur (Q) ainsi que son application 
au moyen de l'espace de nommage aop de Spring (Q) : 

<bean i d=" todoListsManager I nterceptor"<— © 

cl ass="tudu.servi ce. impl .TodoLi stsManager Interceptor "/> 

<aop:config> 

<aop:aspect id="jmxAspect" 

ref="todoLi stsManager I nterceptor"><—@ 
<aop:pointcut id="coupe" expression="execution(* 

tudu. service. TodoListsManager. *( . . ))"/> 
<aop:around pointcut-ref="coupe" method="invoke"/> 
</aop:aspect> 
</aop:config> 

Pour enregistrer cet intercepteur dans JMX, nous utilisons les fonctionnalites du framework 
Spring par 1' intermediate de la classe MBeanExporter (Q) : 

<bean id="exporter" 

cl ass="org.springf ramework. jmx. export. MBeanExporter "> 
<property name="beans"> 
<map> 
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<entry 

key="tudu:servi ce=todoLi stsManagerInterceptor"<— Q 
val ue-ref="todoLi stsManager Interceptor" /> 

</map> 
</property> 

<property name="server" ref="mbeanServer" /> 
</bean> 

La supervision 

Une fois notre infrastructure JMX en place et nos differents MBeans enregistres dans le 
serveur JMX, nous pouvons observer revolution de leurs multiples proprietes grace a la 
console MC4J et ses outils graphiques. 

Nous demarrons Tomcat dans un premier temps puis nous connectons depuis la console MC4J 
sur le serveur JMX embarque. Nous constatons 1' apparition des differents MBeans du serveur, 
incluant ceux concernant Hibernate et les services de Tudu Lists. 

La figure 18-7 illustre Farborescence des MBeans dans la console MC4J. 
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Figure 18-7 

Hierarchie des MBeans dans la console MC4J 
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La console permet egalement de visualiser en temps reel et de maniere graphique la valeur de 
la propriete numberOfCal 1 de l'intercepteur du service todoListsManagerlnterceptor, comme 
l'illustre la figure 18-8. 
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Courbe d' evolution des 
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La console permet egalement de consulter des statistiques d'utilisation d'Hibernate, telles que le 
nombre d'entites chargees depuis le demarrage de Fapplication, comme l'illustre la figure 18-9. 



Figure 18-9 

Statistiques d 'utilisation 
d'Hibernate 
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Chapitre 18 



Grace a un adaptateur pour le protocole HTTP, nous pouvons en outre visualiser les differents 
MBeans dans un navigateur Web au format XML, le format par defaut de MX4J (voir 
figure 18-10). 



- <Swnt> 

<MBean classiiame="m»4j server mtciccptor ContcxtClassLoadcrMBcaiiServcrlnterccptor" description- 'MBeanServer interceptor' 
objeemame="JMImplememarionmterceptor=coMe!aclassloaderY-' 

•"MBean classname-'mifli server interceptor InvolcerMBeanServerlnterceptor" description - The interceptor that invoices on the MBean instance' 
objectname="JMmiplemeiitanoiuiiterccptor=invokcr7> 

vMBean dassname="mx4j server interceptor NottficationListenerMBeanServerlnterceptor" description— 'MBeanServer interceptor' 
obicctnamc - ''JMIniplementahoninterceptor~notificahonwrapper7> 

< MBean dassname="mx4j server interceptor SecuiityMBeanServcrlnterccptor' desciiption=Thc interceptor that performs security checks for MBeanServer to 
MBean calls" objecmame^JMImplementahontnterceptor=secunry7> 

''MBean dassnamc - "m:i 1 1 server MX'lJMBeanServerDelegate" dcscnption-'Manageable Bean" 
objectname="JMIniplement^on:type=MBeanServerDclegate7> 

<- MBean dassname='mx4j server interceptor MBeanServer InterceptorConfigurator" de-sciipfion-'Configiirator for MBeanServer to MBean interceptors" 
objectnamc - "JMIrnplementahontype-MBeanServerlnterceptorC'onfiscurator'/^ 

<MBean dassiiarae="mx4j tools adaptor hrtp IlttpAdaptor" desciiption='lIttpAdaptoi' MBcaii" objettiiaine="Sci'vcr naine=IIttpAdaptor , /> 
<-MBean classiiame="javax management remote rmi RMIConnectorServer" de-scription-'Manageable Bean" obje-cmame='coimectorname=rmi7'.> 
''MBean dassname-' or&hibemate jmx StahsticsService' description - 'Manageable Bean' objectname-'tudu service-hibemateStahsacs"/^ 
< MBean classname="tudu service implTodoUstsManagerlnterccptor" desuiption-'tudu service implTodoListsManagcrlnterceptor" 
objecmame="nidu:service=todoListsManagerInterceptor"/> 



Le support JMX de Spring offre une grande flexibilite d' utilisation, ainsi que de nombreuses 
fonctionnalites qui facilitent sa mise en ceuvre au sein des applications d'entreprise. Les 
divers composants en jeu se configurent directement et simplement dans le contexte de 
Spring. 

Differentes strategies sont fournies pour permettre de determiner precisement les proprietes et 
methodes a rendre accessibles dans JMX. II est egalement possible d'exposer de maniere 
transparente de simples Beans. Ainsi, des composants peuvent etre exposes dans JMX au 
moment de 1' assemblage de 1' application sans aucun developpement supplementaire. 

Le support fournit enfin un ensemble de classes qui rendent possible d'embarquer son propre 
serveur JMX, ainsi que de se connecter et d'interagir avec diverses entites de JMX, comme les 
connecteurs et les observateurs de notifications de MBeans. 



Figure 18-10 

Affichage des MBeans dans un navigateur Web 
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Tirez le meilleur parti de Java EE avec Spring ! 

Cet ouvrage montre comment developper des applications Java EE professionnelles performantes 
a I'aide du framework Spring. L'ouvrage presente les concepts sur lesquels reposent Spring 
[conteneur leger, injection de dependances, programmation oriente aspect] avant de detailler les 
differentes facettes du developpement d'applications d'entreprise avec Spring : couche presenta- 
tion, persistance des donnees et gestion des transactions, integration avec d'autres applications 
et securite applicative. 

Cette seconde edition presente en detail les nouveautes majeures des versions 2.5 et 3.0 de 
Spring et de ses modules annexes : modele de programmation base sur les annotations, Spring 
Dynamic Modules for OSGi, Spring Batch, Spring Security, SpringSource dm Server, etc. L'accent 
est mis tout particulierement sur les bonnes pratiques de conception et de developpement, qui 
sont illustrees a travers une etude de cas detaillee, le projet Open Source Tudu Lists. 



Au sommaire 

Les fondations de Spring. Le conteneur leger de Spring • Les concepts avances du conteneur Spring • Les concepts 
de la POA (programmation orientee aspect) • Spring AOP • Test des applications Spring. Les frameworks de pre- 
sentation. Spring MVC • Spring Web Flow • Utilisation d'Ajax avec Spring (DWR, GWT). Gestion des donnees. Per- 
sistance des donnees • Gestion des transactions • Support de JMS et JCA. Technologies d'integration. Spring Web 
Services • Spring Security • Spring Batch. Spring en prodoction. Spring Dynamic Modules et OSGi • SpringSource 
dm Server • Supervision avec JMX. 



Sur le site www.springparlapratique.org 

- Dialoguez avec les auteurs et participez au forum de discussion 

- Accedez au code source de I'etude de cas du livre 

- Decouvrez les complements et mises a jour 

- Telechargez les annexes au format pdf [Spring IDE, Developpement OSGi dans Eclipse, 
Industrialisation des developpements Spring dans Eclipse) 
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